Re: Wrong stats for empty tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Emmanuel Cecchet <Emmanuel(dot)Cecchet(at)asterdata(dot)com>, pgsql-hackers(at)postgresql(dot)org, manu(at)frogthinker(dot)org
Subject: Re: Wrong stats for empty tables
Date: 2009-05-05 22:27:12
Message-ID: 13505.1241562432@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> On 5/5/09 9:52 AM, Tom Lane wrote:
>> No, it's intentional.

> Huh? Why would we want wrong stats?

Tables rarely stay empty; and a plan generated on the assumption that a
table is empty is likely to suck much more when the table stops being
empty than a plan generated on the assumption that the table contains
some data will suck when it really doesn't. Neither case is really
attractive, but the downside of a size underestimate tends to be a
lot worse than that of an overestimate.

This decision was made before we had autovacuum/autoanalyze support
or the ability to replan automatically after a stats update, but I think
it's still good even now that we do. You can add a hundred or so tuples
to an empty table before autovac will deign to pay attention, and that's
more than enough to blow a nestloop plan out of the water. Also, the
most common case for this type of issue is a temp table, which autovac
can't help with at all.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-05-05 23:07:51 Re: Patch to fix search_path defencies with pg_bench
Previous Message Tom Lane 2009-05-05 22:15:21 Re: "could not reattach to shared memory" captured in buildfarm