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

Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 GUCvariable
Date: 2008-01-30 20:25:02
Message-ID: 1201724702.4453.159.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Wed, 2008-01-30 at 18:42 +0000, Heikki Linnakangas wrote:
> 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.

> 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.

You're right, but in practice its not quite that bad with the
multi-table route. When you have partitions you generally exclude most
of them, with typically 1-2 per query, usually different ones.

If you were scanning lots of partitions in sequence so frequently that
you'd get benefit from synch scans then your partitioning scheme isn't
working for you - and that is the worst problem by far.

But yes, it does need to be addressed.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com 


In response to

Responses

pgsql-hackers by date

Next:From: Gregory StarkDate: 2008-01-30 20:27:47
Subject: Re: Will PostgreSQL get ported to CUDA?
Previous:From: Heikki LinnakangasDate: 2008-01-30 18:42:04
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable

pgsql-patches by date

Next:From: Heikki LinnakangasDate: 2008-01-30 20:55:22
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous:From: Heikki LinnakangasDate: 2008-01-30 18:42:04
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable

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