Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

Next:From: Bruno Almeida do LagoDate: 2005-01-21 00:40:02
Subject: Re: PostgreSQL clustering VS MySQL clustering
Previous:From: Bruno Wolff IIIDate: 2005-01-21 00:14:27
Subject: Re:

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group