4 ms·

Perhaps a better way to ask the question is: If you had to choose between DB system A and DB system B which were functionally equivalent and the only differenc

Perhaps a better way to ask the question is: If you had to choose between DB system A and DB system B which were functionally equivalent and the only difference between them is that system A required you to create and maintain indexes to get the same level of performance as system B does without needing this step; how important would that feature be to you when making the decision? For me, I would choose system B over system A every day of the week and twice on Sunday. But if everyone else just says 'Meh' to that characteristic, then I don't want to spend much time promoting it. My system has a bunch of other features that I think are really good too, so if that is the case I would rather just focus on promoting them instead.

TristanBall 4y ago
If the system can run without indexes while still being performant in other areas ( multiuser oltp for example ) then that's awesome, absolutely. Pretty much every other trick for faster multi-record queries sacrifices oltp performance in some way. But to step back a bit. DBA's manage database engines as much as they manage the data, often more. Schema design, index maintenance etc is part of it, but on a stable system often only a small part. And replacing those db engines is a big deal, as per my earlier comments about compatability and integration - without big, strategic management support, it's often effectively impossible to change them. So you're offering a choice that, in my experience at least, DBA's actually rarely make - coders, architects and history usually make, or made those choices. We also often don't care about the data "as information", only in the sense that it's been entrusted to our care. The people who use the data usually wear different hats (bi, ml, analyst, data science, sometimes managers and of course coders ). But those people aren't adding / removing indexes in DBA managed environments. Your parallel column scan sounds cool, and I can see how it falls naturally from your design, and it's often hard to retro fit onto an older engine. My instances have 11000+ clients during peak, we've already turned off almost all capabilities for parallel queries - because for 95% of the workload it cant help, and likewise an errant query that suddenly jumped up and started consuming multiple cores worth resources could be a disaster. So it sounds like you've got some cool stuff, you're just talking to the wrong demographic!

TristanBall 4y ago

If the system can run without indexes while still being performant in other areas ( multiuser oltp for example ) then that's awesome, absolutely. Pretty much every other trick for faster multi-record queries sacrifices oltp performance in some way. But to step back a bit. DBA's manage database engines as much as they manage the data, often more. Schema design, index maintenance etc is part of it, but on a stable system often only a small part. And replacing those db engines is a big deal, as per my earlier comments about compatability and integration - without big, strategic management support, it's often effectively impossible to change them. So you're offering a choice that, in my experience at least, DBA's actually rarely make - coders, architects and history usually make, or made those choices. We also often don't care about the data "as information", only in the sense that it's been entrusted to our care. The people who use the data usually wear different hats (bi, ml, analyst, data science, sometimes managers and of course coders ). But those people aren't adding / removing indexes in DBA managed environments. Your parallel column scan sounds cool, and I can see how it falls naturally from your design, and it's often hard to retro fit onto an older engine. My instances have 11000+ clients during peak, we've already turned off almost all capabilities for parallel queries - because for 95% of the workload it cant help, and likewise an errant query that suddenly jumped up and started consuming multiple cores worth resources could be a disaster. So it sounds like you've got some cool stuff, you're just talking to the wrong demographic!