Simon Riggs wrote:
Happy New Year, everybody.
This proposal follows on from previous thinking about partitioning,
where I've taken up Andrew Sullivan's suggestion to re-examine the
current partitioning concept of using tables as partitions. So I've come
up with an alternative concept to allow us to discuss the particular
merits of each. ISTM that this new proposal has considerable potential.
I've been lurking and reading a huge number of threads on partitioning.
I see that postgresql is likely to give the user lots of knobs to define
partitions very flexibly, which is a good thing for things like sales
region reports etc.
All that to say, I hope some form of this very automatic tunning makes
it in. This automatic option would provide a benefit (not perfect but
improved) for a significant set of use cases. Even better, it is trivial
to setup, though I would want a knob for the underlying partition sizes,
1GB feels a bit too big for some situations.
Even expensive databases have found I think that there is a cost to
administrative complexity. In many cases someone may not be ready to go
down the declarative path, but be open to allowing the system take some
optimizing approaches. What I especially like is the ability to later
mark things read only. Perhaps a consultant who checks in on things
monthly might mark partitions in that form.
Good luck though with it all, great to see this.
- August
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
