Re: heap vacuum & cleanup locks
От | Robert Haas |
---|---|
Тема | Re: heap vacuum & cleanup locks |
Дата | |
Msg-id | CA+TgmoaUPCyD4yexOW6NeLRKZuEKgxmj9hofU8BiXFvuuPaZUw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: heap vacuum & cleanup locks (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
On Tue, Nov 8, 2011 at 10:08 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Tue, Nov 8, 2011 at 1:50 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> But there's an efficiency argument against doing it that way. First, >> if we release the pin then we'll have to reacquire the buffer, which >> means taking and releasing a BufMappingLock, the buffer header >> spinlock, and the buffer content lock. Second, instead of returning a >> pointer to the data in the page, we'll have to copy the data out of >> the buffer before releasing the pin. > > The only way I can see this working is to optimise this in the > planner, so that when we have a nested loop within a loop, we avoid > having the row on the outer loop pinned while we perform the inner > loop. Hmm. I've actually never run into a problem that involved that particular situation. In any case, I think the issues are basically the same: keeping the pin improves performance; dropping it helps VACUUM. Both are important. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: