Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Hans-Jürgen Schönig <postgres@cybertec.at>
From: Hans-Juergen Schoenig <postgres@cybertec.at>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Neil Conway <neilc@samurai.com>, Gregory Stark <stark@enterprisedb.com>, "Jonah H. Harris" <jonah.harris@gmail.com>, pgsql-hackers@postgreSQL.org
Date: 2008-01-28T18:44:58Z
Lists: pgsql-hackers
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@samurai.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