Noah Misch writes:
> You may want to compare your patch to this pending patch for the same bug:
> http://www.postgresql.org/message-id/flat/24f09c2d-e5bf-1f73-db54-8255c1280...@2ndquadrant.com
Oh, interesting. I had not been paying any attention to that thread.
I'll go respond over there.
On Wed, May 25, 2016 at 05:50:41PM -0400, Tom Lane wrote:
> I wrote:
> > OK. I'm going to work on replacing the DBWriteRequest structure with
> > an OID list, and on improving the comments some more, but I don't
> > anticipate further functional changes.
>
> Here's the end result of that.
You ma
I wrote:
> OK. I'm going to work on replacing the DBWriteRequest structure with
> an OID list, and on improving the comments some more, but I don't
> anticipate further functional changes.
Here's the end result of that. I went ahead and pushed the original
small patch, concluding that that was f
Michael Paquier writes:
> On Tue, May 24, 2016 at 3:52 PM, Tom Lane wrote:
>> True, although I'm not sure if adding a dependency on IsSharedRelation()
>> here is a good thing. In any case, you took the dependency too far ...
> OK. It seemed more simple to me to have the dependency on catalog.h
On Tue, May 24, 2016 at 3:52 PM, Tom Lane wrote:
> Michael Paquier writes:
>> At the same time I am not getting why pgstat_fetch_stat_tabentry needs
>> to be that complicated. Based on the relation OID we can know if it is
>> a shared relation or not, there is no point in doing two times the
>> s
I wrote:
> In short, I think the attached is enough to fix it. There's some cosmetic
> cleanup that could be done here: a lot of these functions could use better
> comments, and I'm not happy about the autovac launcher depending on
> MyDatabaseId being zero. But those are not functional problems.
Michael Paquier writes:
> The problem is different I think. Since 9.3, database-related
> statistics are located on separate files. And the statistics of shared
> tables is visibly located in a file with database name set as
> InvalidOid, leading to the presence of db_0.stat in pg_stat_tmp. So
> t
On Tue, Feb 2, 2016 at 10:38 AM, Jim Nasby wrote:
> On 2/1/16 7:20 PM, Peter Eisentraut wrote:
>> That's probably right. Even with autovacuum on, the statistics for
>> shared catalogs do not appear as updated right away. That is, if you
>> run VACUUM and then look at pg_stat_sys_tables right awa
On 2/1/16 7:20 PM, Peter Eisentraut wrote:
That's probably right. Even with autovacuum on, the statistics for
shared catalogs do not appear as updated right away. That is, if you
run VACUUM and then look at pg_stat_sys_tables right away, you will see
the stats for shared catalogs to be slightly
On 2/1/16 9:49 AM, Jim Nasby wrote:
> On 1/30/16 5:05 PM, Peter Eisentraut wrote:
>> When autovacuum is off, the statistics in pg_stat_sys_tables for shared
>> catalogs (e.g., pg_authid, pg_database) never update. So seq_scan
>> doesn't update when you read the table, last_analyze doesn't update w
On 1/30/16 5:05 PM, Peter Eisentraut wrote:
When autovacuum is off, the statistics in pg_stat_sys_tables for shared
catalogs (e.g., pg_authid, pg_database) never update. So seq_scan
doesn't update when you read the table, last_analyze doesn't update when
you run analyze, etc.
But when you shut
When autovacuum is off, the statistics in pg_stat_sys_tables for shared
catalogs (e.g., pg_authid, pg_database) never update. So seq_scan
doesn't update when you read the table, last_analyze doesn't update when
you run analyze, etc.
But when you shut down the server and restart it with autovacuum
12 matches
Mail list logo