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 reassigning
Alvaro Herrera alvhe...@alvh.no-ip.org 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
On Sun, May 30, 2010 at 10:42 PM, Tom Lane t...@sss.pgh.pa.us 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.
Tom Lane t...@sss.pgh.pa.us 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.
Robert Haas robertmh...@gmail.com writes:
On Sun, May 30, 2010 at 10:42 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, May 31, 2010 at 3:42 AM, Tom Lane t...@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
Greg Stark gsst...@mit.edu 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
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 Rennermichael.ren...@amd.co.at 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
Michael Renner michael.ren...@amd.co.at 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
On 16.05.2010 02:16, Tom Lane wrote:
Michael Rennermichael.ren...@amd.co.at 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
12 matches
Mail list logo
