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

Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>,"Neil Conway" <neilc(at)samurai(dot)com>,"Gregory Stark" <stark(at)enterprisedb(dot)com>,"Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>,<pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Date: 2008-01-30 18:42:04
Message-ID: 47A0C4FC.5010806@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>> I'm still not very happy with any of the options here.
> 
>> BAS is great if you didn't want to trash the cache, but its also
>> annoying to people that really did want to load a large table into
>> cache. However we set it, we're going to have problems because not
>> everybody has the same database.
> 
> That argument leads immediately to the conclusion that you need
> per-table control over the behavior.

It's even worse than that. Elsewhere in this thread Simon mentioned a 
partitioned table, where each partition on its own is smaller than the 
threshold, but you're seq scanning several partitions and the total size 
of the seq scans is larger than memory size. In that scenario, you would 
want BAS and synchronized scans, but even a per-table setting wouldn't 
cut it.

One idea would be to look at the access plan and estimate the total size 
of all scans in the plan. Another idea would be to switch to a more seq 
scan resistant cache replacement algorithm, and forget about the threshold.

For synchronized scans to help in the partitioned situation, I guess 
you'd want to synchronize across partitions. If someone is already 
scanning partition 5, you'd want to start from that partition and join 
the pack, instead of starting from partition 1.

I think we'll be wiser after we see some real world use of what we have 
there now..

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-01-30 20:25:02
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous:From: Simon RiggsDate: 2008-01-30 18:15:32
Subject: Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable

pgsql-patches by date

Next:From: Simon RiggsDate: 2008-01-30 20:25:02
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous:From: Simon RiggsDate: 2008-01-30 18:15:32
Subject: Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable

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