From: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Guillaume Cottenceau <gc(at)mnc(dot)ch>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL |
Date: | 2012-11-29 12:45:19 |
Message-ID: | CABOikdMuq-rxJRfL1D3JdUNsq_qfhgafF2bX5yQbO6H_FVZxcA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Nov 29, 2012 at 6:06 PM, Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Blackwell | 2012-11-29 16:38:31 | Re: Savepoints in transactions for speed? |
Previous Message | Andres Freund | 2012-11-29 12:36:13 | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL |