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

Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable

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_scanningGUCvariable
Date: 2008-01-28 23:51:54
Message-ID: 1201564314.4257.815.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Mon, 2008-01-28 at 23:13 +0000, Heikki Linnakangas wrote:
> Tables that are seq scanned are typically very small, like a summary 
> table with just a few rows, or huge tables in a data warehousing 
> system. Between the extremes, I don't think the threshold actually has
> a very big impact.

And if you have a partitioned table with partitions inconveniently
sized? You'd need to *reduce* shared_buffers specifically to get synch
scans and BAS to kick in. Or increase partition size. Both of which
reduce the impact of the benefits we've added.

I don't think the argument that "a table is smaller than shared buffers
therefore it is already in shared buffers" holds true in all cases. I/O
does matter.

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


In response to

Responses

pgsql-hackers by date

Next:From: Caleb WeltonDate: 2008-01-28 23:57:40
Subject: Transition functions for SUM(::int2), SUM(::int4, SUM(::int8])
Previous:From: Jeff DavisDate: 2008-01-28 23:41:05
Subject: Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable

pgsql-patches by date

Next:From: Ron MayerDate: 2008-01-29 00:13:09
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous:From: Jeff DavisDate: 2008-01-28 23:41:05
Subject: Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable

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