Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Hannu Krosing wrote:
>>> The worst that can happen, is a hash collision, in which case you lose
>>> the benefits of sync scans, but you wont degrade compared to non-sync
>>> scans
>
>> But it could cause "mysterious" performance regressions, no?
>
> There are other issues for the "no lock" approach that Jeff proposes.
> Suppose that we have three or four processes that are actually doing
> synchronized scans of the same table. They will have current block
> numbers that are similar but probably not identical. They will all be
> scribbling on the same hashtable location. So if another process comes
> along to join the "pack", it might get the highest active block number,
> or the lowest, or something in between. Even discounting the possibility
> that it gets random bits because it managed to read the value
> non-atomically, how well is that really going to work?
Could that be adressed by something along the line of
"Don't update the block number if the new value is between
the current number and the current number - update count/2" (
Update count being the number of blocks a backend reads before
updating the hashtable again). At least this would prefent
needless updates to nearly the same block number, which would
help NUMA-Style architectures like Opteron Systems I think.
> Another thing that we have to consider is that the actual block read
> requests will likely be distributed among the "pack leaders", rather
> than all being issued by one process. AFAIK this will destroy the
> kernel's ability to do read-ahead, because it will fail to recognize
> that sequential reads are being issued --- any single process is *not*
> reading sequentially, and I think that read-ahead scheduling is
> generally driven off single-process behavior rather than the emergent
> behavior of the whole system. (Feel free to contradict me if you've
> actually read any kernel code that does this.) It might still be better
> than unsynchronized reads, but it'd be leaving a lot on the table.
I don't see why a single process wouldn't be reading sequentially - As far
as I understood the original proposal, the current blocknumber from the
hashtable is only used as a starting point for sequential scans. After that,
each backend reads sequentiall until the end of the table I believe, no?
greetings, Florian Pflug