| From: | "Mark Liberman" <mliberman(at)mixedsignals(dot)com> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "Sriram Dandapani" <sdandapani(at)counterpane(dot)com> |
| Cc: | <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: Tale partitioning |
| Date: | 2006-05-05 01:48:25 |
| Message-ID: | 9D938282F8C6EE43B748B910386DE93E0138B441@srvgpimail1.GPI.local |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
>BTW, I should have mentioned that partitioning is a very new feature and
>that folks probably would like to know about shortcommings you find
>while using it.
We just implemented partitioning, and have found it very useful for dropping old data, as opposed to deleting and enduring the subsequent vacuum.
One unforeseen issue we ran into had to do with postgres basing it's execution plans on the master-table (which is generally empty) and therefore choosing inefficient merge-joins, in our case. The work-around, however, was for us to delete the rows in pg_statistics for the master tables, as this thread indicates.
http://archives.postgresql.org/pgsql-performance/2006-05/msg00024.php
Once we employed the work-around things seem good.
- Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruno Wolff III | 2006-05-05 02:43:33 | Re: reset all sequences |
| Previous Message | Sriram Dandapani | 2006-05-04 21:20:39 | reset all sequences |