Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
От | Simon Riggs |
---|---|
Тема | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |
Дата | |
Msg-id | 1201540479.4257.737.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |
Список | pgsql-hackers |
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 ;-) -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: