Added to TODO:
Improve CLUSTER performance by sorting to reduce random I/O
* http://archives.postgresql.org/pgsql-hackers/2008-08/msg01371.php
---
Gregory Stark wrote:
>
> One thing that's bee
Gregory Stark <[EMAIL PROTECTED]> writes:
> In particular I'm thinking of people clustering on a covering index (which
> isn't as uncommon as it sounds, if you have a covering index you probably do
> want to cluster it -- consider many-to-many join tables). We should be able to
> do an index-only s
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Yeah, I've been thinking about how to use the planner to do this.
>
> I thought the answer to that was going to be more or less "call
> cost_sort() and cost_index() and compare the answers".
That was the way I was
Gregory Stark <[EMAIL PROTECTED]> writes:
> Yeah, I've been thinking about how to use the planner to do this.
I thought the answer to that was going to be more or less "call
cost_sort() and cost_index() and compare the answers".
> To do that it seems to me what we would need to do is add a functi
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> I think there needs to be an option to force this to do either sorts or
>> indexscans.
>
> If we use the planner, "set enable_indexscan =off" or "set enable_sort=off"
> ought to work.
Yeah, I've been thinking about how to us
On Mon, 2008-09-08 at 13:52 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I think there needs to be an option to force this to do either sorts or
> > indexscans.
>
> If we use the planner, "set enable_indexscan =off" or "set
> enable_sort=off" ought to work.
Agreed - as long as tha
Simon Riggs wrote:
I think there needs to be an option to force this to do either sorts or
indexscans.
If we use the planner, "set enable_indexscan =off" or "set
enable_sort=off" ought to work.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers m
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 .
Gregory Stark <[EMAIL PROTECTED]> writes:
> There are a couple problems with this:
> a) We need some way to decide *when* to do a sort and when to do an index
> scan. The planner has all this machinery but we don't really have all the
> pieces handy to use it in a utility statement.
Why not? You
Martijn van Oosterhout wrote:
On Mon, Sep 01, 2008 at 12:25:26AM +0100, Gregory Stark wrote:
The problem is that it does a full index scan and looks up each tuple in the
order of the index. That means it a) is doing a lot of random i/o and b) has
to access the same pages over and over again.
On Mon, Sep 01, 2008 at 12:25:26AM +0100, Gregory Stark wrote:
> The problem is that it does a full index scan and looks up each tuple in the
> order of the index. That means it a) is doing a lot of random i/o and b) has
> to access the same pages over and over again.
> a) We need some way to de
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.
The problem is that it does a full index scan and looks up each tuple in the
order of the index. That means it a) is doing a lot of ra
12 matches
Mail list logo
