Re: Dynamic Partitioning using Segment Visibility Maps - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Dynamic Partitioning using Segment Visibility Maps
Date
Msg-id 1200052190.4266.1018.camel@ebony.site
Whole thread Raw
In response to Re: Dynamic Partitioning using Segment Visibility Maps  (Gavin Sherry <swm@alcove.com.au>)
Responses Re: Dynamic Partitioning using Segment Visibility Maps  (Gavin Sherry <swm@alcove.com.au>)
List pgsql-hackers
On Fri, 2008-01-11 at 10:25 +0100, Gavin Sherry wrote:
> > 
> > Of course. It's an identical situation for both. Regrettably, none of
> > your comments about dynamic partitioning and planning were accurate as a
> > result. 
> 
> That's not true. We will still have planning drive the partition
> selection when the predicate is immutable, thus having more accurate
> plans. 

Not really.

The planner already evaluates stable functions at plan time to estimate
selectivity against statistics. It can do the same here.

The boundary values can't be completely trusted at plan time because
they are dynamic, but they're at least as accurate as ANALYZE statistics
(and probably derived at identical times), so can be used as estimates.
So I don't see any reason to imagine the plans will be badly adrift.

We're back to saying that if the visibility map is volatile, then SE
won't help you much. I agree with that and haven't argued otherwise.
Does saying it make us throw away SE? No, at least, not yet and not for
that reason.

SE does what I was looking for it to do, but doesn't do all of what
you'd like to achieve with partitioning, because we're looking at
different use cases. I'm sure you'd agree that all large databases are
not the same and that they can have very different requirements. I'd
characterise our recent positions on this that I've been focused on
archival requirements, whereas you've been focused on data warehousing.
The difference really lies in how much activity and of what kind occurs
on a table. You don't unload and reload archives regularly, nor do you
perform random updates against the whole table. I'm sure we'd quickly
agree that many of the challenges you've seen recently at Greenplum
would not be possible with core Postgres, so I'm not really trying too
hard to compete.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Csaba Nagy
Date:
Subject: Re: Storage Model for Partitioning
Next
From: Richard Huxton
Date:
Subject: Re: Storage Model for Partitioning