Re: Page at a time index scan
От | Simon Riggs |
---|---|
Тема | Re: Page at a time index scan |
Дата | |
Msg-id | 1146669815.449.131.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Page at a time index scan (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Page at a time index scan
|
Список | pgsql-patches |
On Wed, 2006-05-03 at 10:56 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > On Tue, 2006-05-02 at 15:35 -0400, Tom Lane wrote: > >> This is unnecessary and probably wrong. > > > You'll need to be more specific about what you mean. > > There is no point in marking a page half-dead, as that doesn't save > anyone else from visiting it, and it's probably wrong to mark a leaf > page as half-dead at all. That state is associated with upper pages. > > Even if it were a legal tree configuration, marking the page half-dead > would make it impossible to insert any more keys in the page, which > doesn't strike me as an appropriate behavior; it's likely to force > excess I/O later due to unnecessary page splits during future inserts. OK. So do you see a problem scenario like this? A, B and C separate backends: A1 Reads page, some row versions are *not* marked LP_DELETE but will be later when A2 happens B1 VACUUM removes dead rows, just happens to be all of them B2 Recycles page into FSM C1 Inserts new data into old page A2 Attempts to update old page to notify about dead rows (UGH!) B2 can only stopped by pinning... -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: