Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
От | Heikki Linnakangas |
---|---|
Тема | Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable |
Дата | |
Msg-id | 47A0E43A.7050106@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
Simon Riggs wrote: > On Wed, 2008-01-30 at 18:42 +0000, Heikki Linnakangas wrote: >> It's even worse than that. Elsewhere in this thread Simon mentioned a >> partitioned table, where each partition on its own is smaller than the >> threshold, but you're seq scanning several partitions and the total size >> of the seq scans is larger than memory size. In that scenario, you would >> want BAS and synchronized scans, but even a per-table setting wouldn't >> cut it. > >> For synchronized scans to help in the partitioned situation, I guess >> you'd want to synchronize across partitions. If someone is already >> scanning partition 5, you'd want to start from that partition and join >> the pack, instead of starting from partition 1. > > You're right, but in practice its not quite that bad with the > multi-table route. When you have partitions you generally exclude most > of them, with typically 1-2 per query, usually different ones. Yep. And in that case, you *don't'* want BAS or sync scans to kick in, because you're only accessing a relatively small chunk of data, and it's worthwhile to cache it. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: