Re: partitioning question 1

From: "Igor Neyman" <ineyman(at)perceptron(dot)com>
To: "Ben" <midfield(at)gmail(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: partitioning question 1
Date: 2010-10-29 16:28:20
Message-ID: F4C27E77F7A33E4CA98C19A9DC6722A206ADF455@EXCHANGE.corp.perceptron.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> -----Original Message-----
> From: Ben [mailto:midfield(at)gmail(dot)com]
> Sent: Friday, October 29, 2010 12:16 PM
> To: Igor Neyman
> Cc: pgsql-performance(at)postgresql(dot)org
> Subject: Re: partitioning question 1
>
> On Oct 29, 2010, at 7:38 AM, Igor Neyman wrote:
>
> >> is my intuition completely off on this?
> >>
> >> best regards, ben
> >>
> >
> > If your SELECT retrieves substantial amount of records, table scan
> > could be more efficient than index access.
> >
> > Now, if while retrieving large amount of records "WHERE clause" of
> > this SELECT still satisfies constraints on some partition(s), then
> > obviously one (or few) partition scans will be more efficient than
> > full table scan of non-partitioned table.
> >
> > So, yes partitioning provides performance improvements, not only
> > maintenance convenience.
>
> my impression was that a *clustered* index would give a lot
> of the same I/O benefits, in a more flexible way. if you're
> clustered on the column in question, then an index scan for a
> range is much like a sequential scan over a partition (as far
> as i understand.)
>
> b
>

Even with clustered index you still read index+table, which is more
expensive than just table scan (in situation I described above).
PG clustered index is not the same as SQL Server clustered index (which
includes actual table pages on the leaf level).

Igor Neyman

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jon Nelson 2010-10-29 16:40:24 typoed column name, but postgres didn't grump
Previous Message Ben 2010-10-29 16:16:13 Re: partitioning question 1