testing generic table

[miekg]

I might be worth testing with a database that stores the rdata in a generic way and sees how much that impact the performance.

What this generic rdata should look like is an interesting question, esp. coming from CoreDNS that uses go-dns for internal representation. May use https://golang.org/pkg/encoding/gob/ ?

This request comes mostly from my spider sense going off when you need to "upgrade your database" to implement a new record.

[thoro]

For that I would also suggest some kind of cli utility to insert into the database

[miekg]

yep. Or, at the least, a converter.

Within the context of CoreDNS we should aim to keep it read-only, so another process fills the database (from an AXFR/IXFR?) and multiple coredns instances serve from it

[thoro]

Yep, definitly external to Coredns, but using your dns library with all the objects in there.

A mapper/encode could take out the common columns, and build a wrapper object around with created_at / updated_at / zone/ id information

[miekg]

yes, at least that what I'm thinking here. You basically have a dns.MsgHeader on file in the rdata by decoding the Gob for this specific RR.

[thoro]

for that I would think about a config option:

schema explicit = every record has a separate table schema compressed = single records table

so you can decide what you prefer

[miekg]

Sure, it's your code :) I just think a generic database is easier from an ops standpoint.