Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
От | Zeugswetter Andreas ADI SD |
---|---|
Тема | Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable |
Дата | |
Msg-id | E1539E0ED7043848906A8FF995BDA57902C23F2F@m0143.s-mxs.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
|
Список | pgsql-hackers |
> > +1. If we go with 'enable_sync_seqcans' for 8.3, and in a future release > > cycle we do test the cases Simon described above and we agree we need to > > do a fine tune to benefit from this feature, we will need to deprecate > > 'enable_sync_seqscans' and invent another one (sync_seqscans_threshold). > > Looking at this perpective, IMHO we should go with the number (0.25) > > instead of the boolean. > > Surely the risk-of-needing-to-deprecate argument applies ten times more > strongly to a number than a boolean. Yes, I would expect the tuning to be more system than user specific. So imho a boolean userset would couple well with a tuning guc, that may usefully not be userset (if we later discover a need for tuning at all). so +1 for the bool. synchronize[d]_seqscan sounds a bit better in my ears than the plural synchronize_seqscans. To me the latter somehow suggests influece on the whole cluster, probably not worth further discussion though, so if someone says no, ok. Andreas
В списке pgsql-hackers по дате отправления: