Re: CLUSTER and indisclustered - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CLUSTER and indisclustered
Date
Msg-id 6753.1028432228@sss.pgh.pa.us
Whole thread Raw
In response to Re: CLUSTER and indisclustered  (Gavin Sherry <swm@linuxworld.com.au>)
List pgsql-hackers
Gavin Sherry <swm@linuxworld.com.au> writes:
> On Sat, 3 Aug 2002, Tom Lane wrote:
>> AFAICT you're assuming that the table is *exactly* ordered by the
>> clustered attribute.  While this is true at the instant CLUSTER
>> completes, the exact ordering will be destroyed by the first insert or
>> update :-(.  I can't see much value in creating a whole new scan type

> Sorry, I meant to say that heap_insert() etc would need to set
> indisclustered to false.

<<itch>>  You could do that, but only if you are prepared to invent
a mechanism that will instantly invalidate any existing query plans
that assume the clustered ordering is good.

Up to now we've only allowed the planner to make decisions that impact
performace, not correctness of the result.  I'm uncomfortable with the
idea that a "clusterscan" plan could silently return wrong answers after
someone else updates the table and doesn't tell us they did.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: getpid() function
Next
From: Bruce Momjian
Date:
Subject: Re: getpid() function