Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Дата
Msg-id 1201563665.10057.667.camel@dogma.ljc.laika.com
обсуждение исходный текст
Ответ на Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Ответы Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: "Christopher Browne"
Дата:
Сообщение: Re: [PATCHES] Better default_statistics_target
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable