Re: old synchronized scan patch
От | Csaba Nagy |
---|---|
Тема | Re: old synchronized scan patch |
Дата | |
Msg-id | 1165484385.8724.11.camel@coppola.muc.ecircle.de обсуждение исходный текст |
Ответ на | Re: old synchronized scan patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: old synchronized scan patch
|
Список | pgsql-hackers |
> Yah. Something I was idly wondering about: suppose we teach ReadBuffer > to provide an indication whether it had to issue an actual read() or > found the block in cache? Could it be useful to not report the block > location to the hint area if we had to actually read()? That would > eliminate the immediate "pack leader" from the equation. The problem > is that it seems to break things for the case of the first follower > joining a seqscan, because the original leader would never report. > Anyone see the extra idea needed to make this work? 1) How about 2 location hints, one for the actual reads, and one for the followers ? The actual read() case will write to the one, the followers to the other. There could be some magic to make the follower which is getting close to the pack leader to report less often, so that the follower hint will still be covering cached buffers far behind enough (tricky business to tune this), and doesn't skip them immediately. Then some magic to figure out which one to follow... or even try both (at the start of the scan only), and go with the one you had no actual read() on, or the smaller one if both had read() or both didn't. 2) Make the pack leader (as in it had to do actual read()) report less often than the followers (say every 100 read(), while followers report every 10 - numbers made up, no idea what would work best here). This will make the followers hint be more likely to be picked up by new scans, thus better using the existing cache... Cheers, Csaba.
В списке pgsql-hackers по дате отправления: