Gavin Sherry <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
