[PERFORM] Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0

Have been looking at lazyvacuum.c trying to think of a way of changing the calculation of the stats to ensure that my hot table stats do not get so badly distorted. What I have noticed is that when I reindex my hot table the stats on the table do not seem to change in pg_stat_user_tables (ie they

[PERFORM] Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0

Great thanks a lot. We will be ready to build and test a patch or 9.4 version as soon as you have a test patch you want to try. regards Tim -- View this message in context: http://postgresql.1045698.n5.nabble.com/autovacuum-vacuum-creates-bad-statistics-for-planner-when-it-log-index-scans-0

[PERFORM] Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0

Was my example not able to be repeated or do I need to give you a better example of the problem, or is there just a lot of stuff happening? Happy to do more work on example sql for the problem if it needs it, just need some feed back on how whether this problem is going to be looked at or not. re

[PERFORM] Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0

Yes I can create a simpler version that exhibits the problem: postgres_bug_simpler.sql This only now involves one smaller table 60K rows, and a linked table with 20M rows. I tried with 6K and 1M but could not get p

[PERFORM] Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0

I have now created a repeatable test for this ...bug, well that may be debatable, but getting the query plan this wrong after vacum and analyze have run certainly looks like a bug to me. I have created a test case that matches my problem domain but can probably be simplified. postgres_bug.sql

[PERFORM] Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0

Thanks for you response Tom: but what does index_scans:0 mean? vs index scans: 1? I have had a look at the c code but cannot see when it that would be the case. -- View this message in context: http://postgresql.1045698.n5.nabble.com/autovacuum-vacuum-creates-bad-statistics-for-planner-when-it

[PERFORM] Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0

Just to add a little more detail about my busy_table 1) there are no rows deleted 2) 98% of updates are HOT 3) there are two DB's on this postgres instance both with the same table, both seeing the same issue -- View this message in context: http://postgresql.1045698.n5.nabble.com/autovacuum-v

[PERFORM] autovacuum vacuum creates bad statistics for planner when it log index scans: 0

On a 9.3.1 server , I have a key busy_table in that is hit by most transactions running on our system. One DB's copy of this table has 60K rows and 1/3 of that tables rows can updated every minute. Autovacuum autovacuum_analyze_scale_factor is set 0.02, so that analyse runs nearly every minute. Bu