Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable

From: "Stephen Denne" <Stephen(dot)Denne(at)datamail(dot)co(dot)nz>
To: "Jeff Davis" <pgsql(at)j-davis(dot)com>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable
Date: 2008-01-29 22:33:39
Message-ID: F0238EBA67824444BC1CB4700960CB48048E0F48@dmpeints002.isotach.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Jeff Davis wrote
> > Well clusteredness is used or could be used for a few
> different heuristics,
> > not all of which this would be quite as well satisfied as
> readahead. But for
>
> Can you give an example? Treating a file as a circular structure does
> not impose any significant cost that I can see.

(Pure speculation follows... if you prefer facts, skip this noise)

The data used to create pg_stats.correlation is involved in estimating the cost of an index scan.
It could also be used in estimating the cost of a sequential scan, if the query includes a limit.

Consider:
select * from huge_table_clustered_by_A where A<most_As limit 1000

If the correlation for A is close to 1, a sequential scan should be cheaper than an index scan.

(If the query also included an order by clause, the sequential scan would have to read the entire table to ensure it had found the top 1000, instead of any old 1000 returned in order)

If A is a circular structure, you would have to know where it started, and include this info in the dump/restore (or lose A's correlation).

Stephen Denne.

Disclaimer:
At the Datamail Group we value team commitment, respect, achievement, customer focus, and courage. This email with any attachments is confidential and may be subject to legal privilege. If it is not intended for you please advise by reply immediately, destroy it and do not copy, disclose or use it in any way.

__________________________________________________________________
This email has been scanned by the DMZGlobal Business Quality
Electronic Messaging Suite.
Please see http://www.dmzglobal.com/services/bqem.htm for details.
__________________________________________________________________

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2008-01-29 22:42:58 Win32: Building with Longhorn SDK
Previous Message Tom Lane 2008-01-29 22:24:35 Re: Large pgstat.stat file causes I/O storm

Browse pgsql-patches by date

  From Date Subject
Next Message Guillaume Smet 2008-01-30 02:07:10 Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous Message Tom Lane 2008-01-29 22:03:41 Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable