Hi,
Andrew Sullivan wrote:
On Mon, Jan 07, 2008 at 07:16:35PM +0100, Markus Schiltknecht wrote:
Does anything speak against letting the DBA handle partitions as relations?
Yes: it doesn't solve the problem I have, which is that I don't want to have
to manage a whole bunch of tables. I want one table, and I want to be able
to say, "That section is closed".
That's a fair requirement. Wanting to manage partitions manually is
another fair requirement, IMO. They can well coexist.
Remember the requirements: no single tuple in the segment may be
significantly out of the average bounds. Otherwise, the min/max gets
pretty useless and the segment can never be excluded.
The segment can never be excluded in a search on that key, yes. But
consider the likely cases we're looking at:
Uh, which key are you talking about? AFAIU Simon's proposal, he suggests
maintaining min/max values for all columns of the table.
WHERE some_date >= '1999-01-01' AND some_date < '2001-01-01';
Yeah, and if only *one* tuple in the 1G segment has:
some_date <= '1998-12-31' OR some_date >= '2001-01-01'
Segment Exclusion can't exclude that segment. That's all I'm saying.
That said, I am not trying to argue it should be adopted without poking at
its weaknesses. I just think it unfair to ask the proposal to address
problems it's not really aimed at.
Huh? I'm certainly not the one asking for it. Quite the opposite, I'm
warning from over-estimating the use of SE.
In his proposal, Simon was explicitly comparing to "declarative
partitioning", pointing out lots of advantages and implicitly stating
that SE could cover most, if not all needs of what's commonly understand
by partitioning. That's where I disagree.
But certainly, SE and SVM has some merit for it's use case. And I'm
looking forward to test patches ;-)
Regards
Markus
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
