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
