To mitigate the need for per-table tuning of autovacuum configuration, I'd
like to propose a new GUC for autovacuum_vacuum_threshold_max.
Currently, it seems that I can either set autovacuum_vacuum_scale_factor
much smaller than default on tables with millions of rows, or set a value
globally that
Thanks for closing the loop on the data correlation question. I've been
playing with BRIN indexes on a log table of sorts and this thread helped
clear up some of the behavior I have been seeing.
I am curious, would a partial btree index fit your needs? Perhaps the
maintenance overhead is too signi
On Thu, Oct 10, 2019 at 6:22 PM David Rowley
wrote:
> The planner might be able to get a better estimate on the number of
> matching rows if the now() - interval '10 days' expression was
> replaced with 'now'::timestamptz - interval '10 days'. However, care
> would need to be taken to ensure the
Since the optimizer is choosing a seq scan over index scan when it seems
like it has good row estimates in both cases, to me that may mean costs of
scanning index are expected to be high. Is this workload on SSD? Has the
random_page_cost config been decreased from default 4 (compared with cost
of 1
