Re: column without pg_stats entry?!

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.

In response to

Responses

Browse pgsql-performance by date

  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: