Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL - Mailing list pgsql-performance

From Pavan Deolasee
Subject Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL
Date
Msg-id CABOikdMuq-rxJRfL1D3JdUNsq_qfhgafF2bX5yQbO6H_FVZxcA@mail.gmail.com
Whole thread Raw
In response to Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-performance


On Thu, Nov 29, 2012 at 6:06 PM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2012-11-29 17:59:39 +0530, Pavan Deolasee wrote:

>
>
> Yeah, that looks fairly easy to have. Thinking about it more, now that we
> have ability to skip WAL for the case when a table is created and populated
> in the same transaction, we could also set the visibility map bits for such
> a table (if we are not doing that already). That should be fairly safe too.

I don't think the latter would be safe at all. Every repeatable read
transaction that started before the table creation would see that tables
content based on the visibilitymap instead of seeing it as empty.

Yeah, but that should be easy to fix, no ? We know the transaction that created the table and we can check if that transaction is visible to our snapshot or not. If the creating transaction itself is not visible, the data in the table is not visible either. OTOH if the creating transaction is visible and is committed, we can trust the visibility map as well. Thats probably better than scanning the entire table just to find that we can/can't see all/any rows.

Its getting slightly off-topic, so my apologies anyways.

Thanks,
Pavan 

pgsql-performance by date:

Previous
From: Andres Freund
Date:
Subject: Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL
Next
From: Mike Blackwell
Date:
Subject: Re: Savepoints in transactions for speed?