Re: Partitioning versus autovacuum - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Partitioning versus autovacuum
Date
Msg-id CAM-w4HOWv_+HDeK9BMw5AeYwi7+ouyaQTaWizdsyNj0K+4s6Jg@mail.gmail.com
Whole thread Raw
In response to Re: Partitioning versus autovacuum  (Greg Stark <stark@mit.edu>)
Responses Re: Partitioning versus autovacuum
List pgsql-hackers
Actually -- I'm sorry to followup to myself (twice) -- but that's
wrong. That Todo item predates the modern partitioning code. It came
from when the partitioned statistics were added for inheritance trees.
The resulting comment almost doesn't make sense any more since it
talks about updates to the parent table and treats them as distinct
from updates to the children.

In any case it's actually not true any more as updates to the parent
table aren't even tracked any more -- see below. My modest proposal is
that we should count any updates that arrive through the parent table
as mods for both the parent and child.

A more ambitious proposal would have updates to the children also
count against the parent somehow but I'm not sure exactly how. And I'm
not sure we shouldn't be updating the parent statistics whenever we
run analyze on a child anyways but again I'm not sure how.

postgres=# postgres=# create table p (i integer primary key, t text)
partition by range (i) ;
CREATE TABLE
postgres=# create table p0 partition of p for values from (0) to (10);
CREATE TABLE
postgres=# analyze p;
ANALYZE
postgres=# analyze p0;
ANALYZE
postgres=# select pg_stat_get_mod_since_analyze('p'::regclass) as p,
pg_stat_get_mod_since_analyze('p0'::regclass) as p0;
 p | p0
---+----
 0 |  0
(1 row)

postgres=# insert into p values (2);
INSERT 0 1
postgres=# select pg_stat_get_mod_since_analyze('p'::regclass) as p,
pg_stat_get_mod_since_analyze('p0'::regclass) as p0;
 p | p0
---+----
 0 |  1
(1 row)



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Commit fest 2019-09
Next
From: Peter Geoghegan
Date:
Subject: Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock(PG10.7)