Tom Lane t...@sss.pgh.pa.us wrote:
Another thing that struck me while looking at the code is that the
curpages clamp is applied to indexes too, which seems like a
thinko. A table occupying a few pages wouldn't likely have an
index as big as the table itself is.
But not zero pages, either.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Another thing that struck me while looking at the code is that the
curpages clamp is applied to indexes too, which seems like a
thinko. A table occupying a few pages wouldn't likely have an
index as big as
Tom Lane wrote:
Another reason not to rely completely on the auto-analyze update path is
that it doesn't work for temp tables, since autovac can't access another
session's temp tables. It's also worth noting that auto-analyze will
never kick in at all for tables of less than about 60 rows,
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Another reason not to rely completely on the auto-analyze update path is
that it doesn't work for temp tables, since autovac can't access another
session's temp tables. It's also worth noting that auto-analyze will
never kick in at all
There's a thread over in pgsql-performance
http://archives.postgresql.org/pgsql-performance/2011-07/msg00046.php
in which the main conclusion was that we need to take a fresh look at the
heuristics the planner uses when dealing with small or empty relations.
The code in question is in
