Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
>> I'm still not very happy with any of the options here.
>
>> BAS is great if you didn't want to trash the cache, but its also
>> annoying to people that really did want to load a large table into
>> cache. However we set it, we're going to have problems because not
>> everybody has the same database.
>
> That argument leads immediately to the conclusion that you need
> per-table control over the behavior.
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.
One idea would be to look at the access plan and estimate the total size
of all scans in the plan. Another idea would be to switch to a more seq
scan resistant cache replacement algorithm, and forget about the threshold.
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.
I think we'll be wiser after we see some real world use of what we have
there now..
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
