On 06/15/2013 11:39 PM, Tom Lane wrote: > There's a nearby thread complaining bitterly about our willingness to > create hard-to-use, hard-to-tune "features". In its current form, > this will be another one of those. For what it's worth, I was going for "usability concerns", not "complaint"... and I'd much rather have most of those features, even with poor usability, than not have them at all. I'm not convinced anyone can introduce something that's beautiful design and implementation perfection first time, every time. Learning where the pain points are and improving them is what I'm going for.
There's also, IMO, nothing wrong with somewhat obscure options for obscure use cases and workloads. The problem is when difficult to understand or weird and obscure parameters need adjustment for perfectly ordinary middle-of-the-road workloads. I'm curious about using minmax indexes to guide insert/update placement, so new tuples are written in regions of the table where they already match the indexed range - essentially providing coarse-grained auto-clustering. Otherwise with updates a table is likely to see scattering of values such that the minmax ranges all keep on expanding and the index becomes less and less selective. I realise that this may not be even remotely feasible, but if it were then it might help reduce the need for explicit tuning. I suspect we'd also land up wanting table optimisation down the track, where tuples were shuffled around during autovacuum to narrow the minmax index ranges. I'm not expressing an opinion on the option discussed here as I haven't worked with enough DBs that'd benefit from it. Personally I'm just seriously impressed that this feature is coming together. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
