| From: | Scott Carey <scott(at)richrelevance(dot)com> |
|---|---|
| To: | "david(at)lang(dot)hm" <david(at)lang(dot)hm>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, henk de wit <henk53602(at)hotmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Transparent table partitioning in future version of PG? |
| Date: | 2009-05-08 19:40:07 |
| Message-ID: | C629D8A7.5C4B%scott@richrelevance.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 5/8/09 11:20 AM, "david(at)lang(dot)hm" <david(at)lang(dot)hm> wrote:
>
> with the Load Balancing Plan there is no benifit in partitioning unless
> you have the ability to run queries on each parition in parallel
>
I think there is a benefit to partitioning in this case. If the statistics
on other columns are highly skewed WRT the column(s) partitioned, the
planner statistics will be better. It may have to access every partition,
but it doesn't have to access every partition in the same way.
Perhaps something like: user_id = 'FOO' is one of the most common vals in
date partition A, and one of the least common vals in B, so a where clause
with user_id = 'FOO' will sequential scan one and index scan another.
For really large tables with data correlation that varies significantly,
this can be a huge performance gain even if all partitions are accessed.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-05-08 20:53:16 | Re: Transparent table partitioning in future version of PG? |
| Previous Message | Fernando Hevia | 2009-05-08 19:04:33 | Re: PostgreSQL with PostGIS on embedded hardware |