| From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Josh Berkus" <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | <jamesr(at)best(dot)com> |
| Subject: | Re: Sponsoring enterprise features |
| Date: | 2003-11-24 11:16:22 |
| Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4962073@m0114.s-mxs.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Main needs partitioning is useful for:
- partition elimination for queries (e.g. seq scans only scan relevant partitions)
- deleting/detaching huge parts of a table in seconds
- attaching huge parts to a table in seconds (that may have been loaded with
a fast loading utility (e.g. loading without index, prebuilding indexes,
attaching table + prebuilt partitioned indexes))
- achieving [heap and index] per page data locality (for better cache rates)
- allowing partial restores (for defect disks) while the rest of the db is still online
- in pg, allowing partial vacuums (only partitions that see changes)
People needing those features usually have data with more than 10-50 Gb per
partition.
> I'm a little unclear, personally, about what can be accomplished through table
> partitioning that we can't currently do through partial indexes and inherited
> tables, especially after Gavin finishes his tablespaces patch
Well, sure the goal needs to be to make use of what already exists,
but a few things are still missing, e.g.:
- unique indexes, that span the hierarchy (and do not contain the partitioning column[s])
- partition elimination (imho we should use check constraints for that)
- physical backups :-)
- tablespaces ?
Note, that these would all be useful for non partitioning
use cases also.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2003-11-24 12:55:01 | Re: Build farm |
| Previous Message | Jean-Michel POURE | 2003-11-24 09:14:48 | Re: Build farm |