Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
От | Tom Lane |
---|---|
Тема | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |
Дата | |
Msg-id | 7380.1201555304@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: [PATCHES] Proposed patch: synchronized_scanning GUC
variable
Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |
Список | pgsql-hackers |
Simon Riggs <simon@2ndquadrant.com> writes: > Rather than having a boolean GUC, we should have a number and make the > parameter "synchronised_scan_threshold". This would open up a can of worms I'd prefer not to touch, having to do with whether the buffer-access-strategy behavior should track that or not. As the note in heapam.c says, * If the table is large relative to NBuffers, use a bulk-read access * strategy and enable synchronized scanning (seesyncscan.c). Although * the thresholds for these features could be different, we make them the * same so thatthere are only two behaviors to tune rather than four. It's a bit late in the cycle to be revisiting that choice. Now we do already have three behaviors to worry about (BAS on and syncscan off) but throwing in a randomly settable knob will take it back to four, and we have no idea how that fourth case will behave. The other tack we could take (having the one GUC variable control both thresholds) is not good since it will result in pg_dump trashing the buffer cache. regards, tom lane
В списке pgsql-hackers по дате отправления: