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
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 |