From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | Bernd Heller <bdheller(at)users(dot)sourceforge(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: column without pg_stats entry?! |
Date: | 2005-01-21 06:02:59 |
Message-ID: | 12411.1106287379@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> Bernd Heller <bdheller(at)users(dot)sourceforge(dot)net> wrote:
>> there is no entry in pg_stats for that column at all!! I can only
>> suspect that this has to do with the column being all null.
> Someone else reported this recently and I think it is going to be fixed.
Yeah, this was griped of a little bit ago, but I felt it was too close
to 8.0 release to risk fooling with for this cycle.
> In the short run you could add an IS NOT NULL clause to your query.
> The optimizer doesn't know that < being TRUE implies IS NOT NULL and
> so the partial index won't be used unless you add that clause explicitly.
Actually, as of 8.0 the optimizer *does* know that. I'm a bit surprised
that it didn't pick the partial index, since even without any analyze
stats, the small physical size of the partial index should have clued it
that there weren't many such tuples. Could we see EXPLAIN output for
both cases (both settings of enable_seqscan)?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-01-21 07:00:03 | Re: PostgreSQL vs. Oracle vs. Microsoft |
Previous Message | Josh Berkus | 2005-01-21 03:49:24 | Re: PostgreSQL clustering VS MySQL clustering |