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.
In response to
pgsql-hackers by date
|Next:||From: Dann Corbit||Date: 2008-01-30 20:56:45|
|Subject: Re: Will PostgreSQL get ported to CUDA?|
|Previous:||From: Dave Page||Date: 2008-01-30 20:29:26|
|Subject: Oops - BF:Mastodon just died|
pgsql-patches by date
|Next:||From: Decibel!||Date: 2008-01-30 22:58:48|
|Subject: Re: [PATCHES] Better default_statistics_target|
|Previous:||From: Simon Riggs||Date: 2008-01-30 20:25:02|
|Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable|