I did a vacuum with -z and it fixed the issue. I was not aware that
vacuumdb didn't ANALYZE by default. Thanks everybody for all of the help!
Tom Lane wrote:
> Benjamin Arai <benjamin(at)araisoft(dot)com> writes:
>> -> Index Scan using mutualfd_weekday_qbid_pkey_idx on
>> mutualfd_weekday_qbid (cost=0.00..6.01 rows=1 width=19) (actual
>> time=34.579..8510.801 rows=253 loops=1)
>> Index Cond: ((pkey >= '2005-12-15'::date) AND (pkey <=
>> Filter: (cusip = '92193920'::text)
> Hm, so how many rows in mutualfd_weekday_qbid for that date?
> And how many satisfy the cusip condition? (I suppose 253,
> but it looks like that must be a very small fraction of all
> the rows for that date.)
> The selectivity estimators are not great about dealing with
> zero-width intervals like this one (in fact, if you look at the
> code you'll find it doesn't even bother to distinguish '>' from '>='
> ... something we should probably try to improve sometime).
> You'd probably have better luck if you could fold the WHERE condition
> down to "pkey = '2005-12-15'". Dunno how feasible that is for your
> regards, tom lane
In response to
pgsql-admin by date
|Next:||From: Rajesh Kumar Mallah||Date: 2006-12-24 10:18:27|
|Subject: psql does not save contents into file at end of command.|
|Previous:||From: Tom Lane||Date: 2006-12-24 01:55:55|
|Subject: Re: [GENERAL] OUTER JOIN IS SLOW |
pgsql-general by date
|Next:||From: postgresql.org||Date: 2006-12-24 03:49:14|
|Subject: Re: Problem with index in OR'd expression|
|Previous:||From: Christopher Browne||Date: 2006-12-24 02:23:14|
|Subject: Re: Clustering & Load Balancing & Replication|