Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Date
Msg-id 1201563665.10057.667.camel@dogma.ljc.laika.com
Whole thread Raw
In response to Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Responses Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-hackers
On Mon, 2008-01-28 at 23:13 +0000, Heikki Linnakangas wrote:
> It's a good point that we don't want pg_dump to screw up the cluster 
> order, but that's the only use case I've seen this far for disabling 
> sync scans. Even that wouldn't matter much if our estimate for 
> "clusteredness" didn't get screwed up by a table that looks like this: 
> "5 6 7 8 9 1 2 3 4"

It doesn't seem like there is any reason for the estimate to get
confused, but it apparently does. I loaded a test table with a similar
distribution to your example, and it shows a correlation of about -0.5,
but it should be as good as something near -1 or +1.

I am not a statistics expert, but it seems like a better measurement
would be: "what is the chance that, if the tuples are close together in
index order, the corresponding heap tuples are close together?".

The answer to that question in your example is "very likely", so there
would be no problem.

Is there a reason we don't do this?

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: "Christopher Browne"
Date:
Subject: Re: [PATCHES] Better default_statistics_target
Next
From: Simon Riggs
Date:
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable