Tom Lane wrote:
> I wrote:
> > In particular, now that there's a distinction between smgr flush
> > and relcache flush, maybe we could associate targblock reset with
> > smgr flush (only) and arrange to not flush the smgr level during
> > ANALYZE --- basically, smgr flush would only be needed when
Tom Lane wrote:
> I wrote:
> > In particular, now that there's a distinction between smgr flush
> > and relcache flush, maybe we could associate targblock reset with
> > smgr flush (only) and arrange to not flush the smgr level during
> > ANALYZE --- basically, smgr flush would only be needed when
I wrote:
> In particular, now that there's a distinction between smgr flush
> and relcache flush, maybe we could associate targblock reset with
> smgr flush (only) and arrange to not flush the smgr level during
> ANALYZE --- basically, smgr flush would only be needed when truncating
> or reassignin
Greg Stark writes:
> This is an analyze-only scan? Why does analyze need to issue a
> relcache flush?
Directly: to cause other backends to pick up the updated pg_class row
(with new relpages/reltuples data).
Indirectly: to cause cached plans for the rel to be invalidated,
so that they can get re
On Mon, May 31, 2010 at 3:42 AM, Tom Lane 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 bac
Robert Haas writes:
> On Sun, May 30, 2010 at 10:42 PM, Tom Lane wrote:
>> pretty clear what is going on. See the logic in
>> RelationGetBufferForTuple, and note that at no time do we have any FSM
>> data for the bid table:
> Is this because, in the absence of updates or deletes, we never vacuu
Tom Lane wrote:
> 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.
>
> 4. Now, all the b
On Sun, May 30, 2010 at 10:42 PM, Tom Lane wrote:
> pretty clear what is going on. See the logic in
> RelationGetBufferForTuple, and note that at no time do we have any FSM
> data for the bid table:
Is this because, in the absence of updates or deletes, we never vacuum it?
> 4. Now, all the bac
Alvaro Herrera writes:
> Excerpts from Michael Renner's message of sáb may 15 20:24:36 -0400 2010:
>>> I've written a simple tool to generate traffic on a database [1], which
>>> did about 30 TX/inserts per second to a table. Upon inspecting the data
>>> in the table, I noticed the expected group
Excerpts from Michael Renner's message of sáb may 15 20:24:36 -0400 2010:
> On 16.05.2010 02:16, Tom Lane wrote:
> > Michael Renner writes:
> >> I've written a simple tool to generate traffic on a database [1], which
> >> did about 30 TX/inserts per second to a table. Upon inspecting the data
> >>
On 16.05.2010 02:16, Tom Lane wrote:
Michael Renner writes:
I've written a simple tool to generate traffic on a database [1], which
did about 30 TX/inserts per second to a table. Upon inspecting the data
in the table, I noticed the expected grouping of tuples which came from
a single backend to
Michael Renner writes:
> I've written a simple tool to generate traffic on a database [1], which
> did about 30 TX/inserts per second to a table. Upon inspecting the data
> in the table, I noticed the expected grouping of tuples which came from
> a single backend to matching pages [2]. The stra
While preparing a replication test setup with 9.0beta1 I noticed strange
page allocation patterns which Andrew Gierth found interesting enough to
report here.
I've written a simple tool to generate traffic on a database [1], which
did about 30 TX/inserts per second to a table. Upon inspecting
13 matches
Mail list logo
