Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL
| От | Pavan Deolasee |
|---|---|
| Тема | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL |
| Дата | |
| Msg-id | CABOikdMuq-rxJRfL1D3JdUNsq_qfhgafF2bX5yQbO6H_FVZxcA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL (Andres Freund <andres@2ndquadrant.com>) |
| Список | pgsql-performance |
On Thu, Nov 29, 2012 at 6:06 PM, Andres Freund <andres@2ndquadrant.com> wrote:
I don't think the latter would be safe at all. Every repeatable readOn 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.
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 по дате отправления: