Re: Unexpected page allocation behavior on insert-only tables - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Unexpected page allocation behavior on insert-only tables
Date
Msg-id AANLkTilTyP3TUBCypf8kspiXpUv1op0eLS-va-meXEBj@mail.gmail.com
Whole thread Raw
In response to Re: Unexpected page allocation behavior on insert-only tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unexpected page allocation behavior on insert-only tables
List pgsql-hackers
On Mon, May 31, 2010 at 3:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> note that at no time do we have any FSM
> data for the bid table:
>
>
> 3. After awhile, autovacuum notices all the insert activity and kicks
> off an autoanalyze on the bid table.  When committed, this forces a
> relcache flush for each other backend's relcache entry for "bid".
> In particular, the smgr targblock gets reset.

This is an analyze-only scan? Why does analyze need to issue a
relcache flush? Maybe we only need to issue one for an actual vacuum
which would also populate the fsm?


--
greg


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Unexpected page allocation behavior on insert-only tables
Next
From: Tom Lane
Date:
Subject: Re: Unexpected page allocation behavior on insert-only tables