Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group