On Tuesday, December 04, 2012 5:14 AM Pavan Deolasee wrote:
On Tue, Dec 4, 2012 at 3:16 AM, Robert Haas wrote:
>>Also, if someone does have a 100GB relation, rereading 2MB of
>>visibility map pages at the end probably isn't a significant part of
>>the total cost. Even if 99.9% of the relation i
On Tue, Dec 4, 2012 at 3:16 AM, Robert Haas wrote:
>
> Also, if someone does have a 100GB relation, rereading 2MB of
> visibility map pages at the end probably isn't a significant part of
> the total cost. Even if 99.9% of the relation is all-visible and we
> skip reading those parts, the visibi
On Mon, Dec 3, 2012 at 1:36 PM, Pavan Deolasee wrote:
> Well, may be the cost is low. But it can still run into several hundred or
> thousand pages that are read into the buffer pool again. If there is indeed
> too much churn happening, an ANALYZE will kick in which will count the bits
> anyway or
On 3 December 2012 18:20, Andres Freund wrote:
> Hi,
>
> On 2012-12-03 23:44:36 +0530, Pavan Deolasee wrote:
>> I wonder if we really need to make another pass over the entire visibility
>> map to count the number of all-visible pages at the end of the vacuum. The
>> code that I'm looking at is in
On Mon, Dec 3, 2012 at 11:50 PM, Andres Freund wrote:
>
>
> A full-table vacuum can take a *long* (as in days) time, so I think
> recounting makes sense. And normally the cost is pretty small, so I
> don't see a problem in this.
>
>
Well, may be the cost is low. But it can still run into several h
Hi,
On 2012-12-03 23:44:36 +0530, Pavan Deolasee wrote:
> I wonder if we really need to make another pass over the entire visibility
> map to count the number of all-visible pages at the end of the vacuum. The
> code that I'm looking at is in src/backend/commands/vacuumlazy.c:
>
> 247 new_rel
I wonder if we really need to make another pass over the entire visibility
map to count the number of all-visible pages at the end of the vacuum. The
code that I'm looking at is in src/backend/commands/vacuumlazy.c:
247 new_rel_allvisible = visibilitymap_count(onerel);
248 if (new_rel_al
