| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | Postgres <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Our CLUSTER implementation is pessimal |
| Date: | 2008-09-04 02:28:05 |
| Message-ID: | 1220495285.4371.819.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2008-09-01 at 00:25 +0100, Gregory Stark wrote:
> One thing that's been annoying me for a while is that our CLUSTER
> implementation is really very slow. When I say very slow I mean it's really
> very very very slow.
Does this implementation work towards being able to do
CREATE INDEX ... CLUSTER TABLE
So that we can do both actions with just one sort of the data?
I think there needs to be an option to force this to do either sorts or
indexscans. On a large table you may not have the space to perform a
full table sort, plus on a multi-column index we may not accurately
predict the cost of an indexscan.
(What is the change to elog.c about?)
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Treat | 2008-09-04 03:15:00 | Re: [PATCH] Cleanup of GUC units code |
| Previous Message | Simon Riggs | 2008-09-04 02:06:42 | Re: hash index improving v3 |