Jeff Davis wrote:
> On Mon, 2007-06-04 at 22:09 +0100, Heikki Linnakangas wrote:
>>> I think the real problem here is that the first scan is leaving state
>>> behind that changes the behavior of the next scan. Which can have no
>>> positive benefit, since obviously the first scan is not still
>>> proceeding; the best you can hope for is that it's a no-op and the worst
>>> case is that it actively pessimizes things. Why doesn't the patch
>>> remove the shmem entry at scan termination?
>> Because there's no reason why it should, and it would require a lot more
>> bookkeeping. There can be many scanners on the same table, so we'd need
>> to implement some kind of reference counting, which means having to
>> reliably decrement the counter when a scan terminates.
>>
>
> That's what I thought at first, and why I didn't do it. Right now I'm
> thinking we could just add the PID to the hint, so that it would only
> remove its own hint. Would that work?
Were you thinking of storing the PID of the backend that originally
created the hint, or updating the PID every time the hint is updated? In
any case, we still wouldn't know if there's other scanners still running.
We could just always remove the hint when a scan ends, and rely on the
fact that if there's other scans still running they will put the hint
back very quickly. There would then be a small window where there's no
hint but a scan is active, and a new scan starting during that window
would fail to synchronize with the other scanners.
> It's still vulnerable to a backend being killed and the hint hanging
> around. However, the next scan would clear get it back to normal.
Oh, did you mean that the PID would be updated whenever a new scan
starts? So that the PID stored would always be the PID of the latest
scanner. That might work pretty well, though a small scan with a LIMIT,
or any other situation where some scans run faster than others, might
clear the hint prematurely while other scans are still running.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
