Re: What needs to be done for real Partitioning? - Mailing list pgsql-performance

From Stacy White
Subject Re: What needs to be done for real Partitioning?
Date
Msg-id 005901c52dd4$e3877830$0200a8c0@grownups
Whole thread Raw
In response to What needs to be done for real Partitioning?  (Josh Berkus <josh@agliodbs.com>)
List pgsql-performance
From: "Tom Lane" <tgl@sss.pgh.pa.us>
> "Stacy White" <harsh@computer.org> writes:
> > FWIW, we see large benefits from partitioning other than the ability to
> > easily drop data, for example:
>
> > - We can vacuum only the active portions of a table
> > - Postgres automatically keeps related records clustered together on
disk,
> > which makes it more likely that the blocks used by common queries can be
> > found in cache
> > - The query engine uses full table scans on the relevant sections of
data,
> > and quickly skips over the irrelevant sections
> > - 'CLUSTER'ing a single partition is likely to be significantly more
> > performant than clustering a large table
> Global indexes would seriously reduce the performance of both vacuum and
> cluster for a single partition, and if you want seq scans you don't need
> an index for that at all.  So the above doesn't strike me as a strong
> argument for global indexes ...

Tom, this list was in response to your question "If you have to do index
cleaning before you can drop a partition, what's the point of
partitioning?".  I was trying to make the point that partioning isn't just
about being able to quickly drop data.  The argument for global indexes came
in the form of my war story and the description of the conditions under
which global indexes will perform better than local indexes (see my original
email for details) .  But, like I said, this would definitely be a phase
II/III item.


pgsql-performance by date:

Previous
From: David Greaves
Date:
Subject: Re: Postgres on RAID5 (possible sync blocking read type
Next
From: Neil Conway
Date:
Subject: Re: View vs function