From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Bernd Heller <bdheller(at)users(dot)sourceforge(dot)net> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: column without pg_stats entry?! |
Date: | 2005-01-21 00:26:20 |
Message-ID: | 20050121002620.GB16417@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Jan 20, 2005 at 11:14:28 +0100,
Bernd Heller <bdheller(at)users(dot)sourceforge(dot)net> wrote:
>
> I wondered why the planner was making such bad assumptions about the
> number of rows to find and had a look at pg_stats. and there was the
> surprise:
> 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. I tried to
> change a few records to a not-null value, but re-ANALYZE didn't catch
> them apparently.
Someone else reported this recently and I think it is going to be fixed.
> Is this desired behaviour for analyze? Can I change it somehow? If not,
> is there a better way to accomplish what I'm trying? I'm not to keen on
> disabling seqscan for that query explicitly. It's a simple enough query
> and the planner should be able to find the right plan without help -
> and I'm sure it would if it had stats about it.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Almeida do Lago | 2005-01-21 00:40:02 | Re: PostgreSQL clustering VS MySQL clustering |
Previous Message | Bruno Wolff III | 2005-01-21 00:14:27 | Re: |