Re: heap vacuum & cleanup locks

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: heap vacuum & cleanup locks
Date: 2011-11-09 22:07:41
Message-ID: CA+U5nMLfcX6wrAjPWZdia8OMzqOKWy7FFboJivU-gBtOu50QhQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 9, 2011 at 9:48 PM, simon <simon(at)2ndQuadrant(dot)com> wrote:
> On Wed, Nov 9, 2011 at 9:12 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>> Well, I'm not sure of the details of how page-at-a-time mode works for
>> seq scans, but I am absolutely 100% sure that you can reproduce this
>> problem using a cursor over a sequential scan.  Just do this:
>>
>> create table test (a text);
>> insert into test values ('aaa'), ('bbb');
>> delete from test where a = 'aaa';
>> begin;
>> declare x cursor for select * from test;
>> fetch next from x;
>
> That's a bug.

No, I'm wrong. It's not a bug at all.

heapgetpage() gets a page and a pin, but holds the pin until it reads
the next page. Wow!

That is both annoying and very dumb. It should hold the pin long
enough to copy the data and then release the pin.

It looks inefficient from a memory access viewpoint and from a pin
longevity viewpoint. If we copied out relevant data it would be more
cache efficient without affecting visibility. Looking at a patch.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2011-11-09 22:08:26 Re: const correctness
Previous Message Thom Brown 2011-11-09 22:00:18 Re: Syntax for partitioning