Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
От | Hans-Juergen Schoenig |
---|---|
Тема | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |
Дата | |
Msg-id | 93EDC9E5-06FD-4EE0-AF0D-117310024B81@cybertec.at обсуждение исходный текст |
Ответ на | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable (Simon Riggs <simon@2ndquadrant.com>) |
Список | 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 aspossible.Currently we set synch scan on when the table is larger than 25% ofshared_buffers. So increasing shared_buffers can actually turn thisfeature off.Rather than having a boolean GUC, we should have a number and make theparameter "synchronised_scan_threshold". This would then be the size ofa table above which we would perform synch scans. If its set to -1, thenthis would be the same as "off" in all cases. The default value would be25% of shared_buffers. (Think we can only do that at initdb timecurrently).If we do that, its clearly different from the enable_* parameters, sothe 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
В списке pgsql-hackers по дате отправления: