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

Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable

From: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
To: Simon Riggs <simon(at)2ndquadrant(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 GUC variable
Date: 2008-01-28 18:44:58
Message-ID: 93EDC9E5-06FD-4EE0-AF0D-117310024B81@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Jan 28, 2008, at 6:14 PM, Simon Riggs wrote:

> On Sun, 2008-01-27 at 21:04 -0500, Tom Lane wrote:
>> [ redirecting thread to -hackers ]
>>
>> Neil Conway <neilc(at)samurai(dot)com> writes:
>>> On Sun, 2008-01-27 at 21:54 +0000, Gregory Stark wrote:
>>>> I liked the "synchronized_sequential_scans" idea myself.
>>
>>> I think that's a bit too long. How about "synchronized_scans", or
>>> "synchronized_seqscans"?
>>
>> We have enable_seqscan already, so that last choice seems to fit in.
>
> If we're going to have a GUC, we may as well make it as useful as
> possible.
>
> Currently we set synch scan on when the table is larger than 25% of
> shared_buffers. So increasing shared_buffers can actually turn this
> feature off.
>
> Rather than having a boolean GUC, we should have a number and make the
> parameter "synchronised_scan_threshold". This would then be the  
> size of
> a table above which we would perform synch scans. If its set to -1,  
> then
> this would be the same as "off" in all cases. The default value  
> would be
> 25% of shared_buffers. (Think we can only do that at initdb time
> currently).
>
> If we do that, its clearly different from the enable_* parameters, so
> the name is easier to decide ;-)


+1
This is in fact a lot more flexible and transparent.
It gives us a lot more control over the process and it is easy to  
explain / understand.

	best regards,

		hans

--
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, 2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at


In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2008-01-28 18:56:30
Subject: Re: [GENERAL] SHA1 on postgres 8.3
Previous:From: Pavel GolubDate: 2008-01-28 18:27:05
Subject: BUG #3909: src\tools\msvc\clean.bat clears parse.h file

pgsql-patches by date

Next:From: Pavel StehuleDate: 2008-01-28 18:56:15
Subject: Re: WIP: plpgsql source code obfuscation
Previous:From: Gregory StarkDate: 2008-01-28 18:37:15
Subject: Re: WIP: plpgsql source code obfuscation

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