Hi,
Here is an example showing the problem:
Welcome to psql 8.3.6, the PostgreSQL interactive terminal.
manu=# create table foo (x int);
CREATE TABLE
manu=# explain select * from foo;
QUERY PLAN
---
Seq Scan on foo
Emmanuel Cecchet emmanuel.cecc...@asterdata.com writes:
Is this a bug?
No, it's intentional.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane [...@sss.pgh.pa.us]
Subject: Re: [HACKERS] Wrong stats for empty tables
Emmanuel Cecchet emmanuel.cecc...@asterdata.com writes:
Is this a bug?
No, it's intentional.
So what is the rationale behind not being able to use indexes and optimizing
empty tables as in the following
On 5/5/09 9:52 AM, Tom Lane wrote:
Emmanuel Cecchetemmanuel.cecc...@asterdata.com writes:
Is this a bug?
No, it's intentional.
Huh? Why would we want wrong stats?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list
Josh Berkus j...@agliodbs.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
On Tue, May 5, 2009 at 2:03 PM, Emmanuel Cecchet
emmanuel.cecc...@asterdata.com wrote:
So what is the rationale behind not being able to use indexes and optimizing
empty tables as in the following example:
manu=# create table father (id int, val int, tex varchar(100), primary
key(id));
