Re: old synchronized scan patch
От | Jeff Davis |
---|---|
Тема | Re: old synchronized scan patch |
Дата | |
Msg-id | 1165453177.2048.112.camel@dogma.v10.wvs обсуждение исходный текст |
Ответ на | Re: old synchronized scan patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: old synchronized scan patch
|
Список | pgsql-hackers |
On Wed, 2006-12-06 at 15:12 -0500, Tom Lane wrote: > > Teamwork requires some synchronisation to be effective, but yeh there > > needs to be a way to leave the Conga if its not working for you/them. > > If we have syncscan members that are spread out over any significant > range of the table's blocks, then the problem of setting the hint > properly becomes a lot more pressing. We'd like incoming joiners to > start at a fairly low block number, ie not become one of the "pack > leaders" but one of the "trailers" --- since the higher they start, > the more blocks they'll need to re-read at the end of their cycles, > yet those are blocks they could have had "for free" if they'd started > as a trailer. I don't see any cheap way to bias the behavior in that > direction, though. > This is speculation, but I suspect that there already is somewhat of a bias favoring the lower block numbers. If you have a pack near the head, and a couple trailers 1000 blocks behind, the trailers are likely to be moving through those blocks very quickly -- and reporting their location much more often -- than the blocks at the head that are awaiting a disk fetch. Even if there are 50 in the pack, and 2 trailing, at any point in time it's more likely that the last block number reported was reported by a trailing scan. The pack might all report at once when they finally get the block, but will be promptly overwritten by the continuous stream of reports from trailing scans. However, if my analysis was really true, one might wonder how those scans got that far behind in the first place. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: