Re: varchar does not work too well with IS NOT NULL partial indexes. - Mailing list pgsql-general

From Dawid Kuroczko
Subject Re: varchar does not work too well with IS NOT NULL partial indexes.
Date
Msg-id 758d5e7f0707240819h37b7b937vd0839bd32c221717@mail.gmail.com
Whole thread Raw
In response to Re: varchar does not work too well with IS NOT NULL partial indexes.  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: varchar does not work too well with IS NOT NULL partial indexes.  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-general
On 7/24/07, Gregory Stark <stark@enterprisedb.com> wrote:
> "Dawid Kuroczko" <qnex42@gmail.com> writes:
>
> > Now, if we:
> >
> > # EXPLAIN ANALYZE SELECT t FROM foo WHERE t='X17';
> >                                            QUERY PLAN
> > ---------------------------------------------------------------------------------------------------
> > Seq Scan on foo  (cost=0.00..18025.78 rows=1 width=8) (actual
> > time=0.079..565.661 rows=1 loops=1)
> >   Filter: ((t)::text = 'X17'::text)
> > Total runtime: 565.689 ms
> >
> >
> > # EXPLAIN ANALYZE SELECT t FROM foo WHERE t='X17';
> >                      QUERY PLAN
> > -------------------------------------------------------
> > Seq Scan on foo  (cost=0.00..178.00 rows=50 width=68)
> >   Filter: ((t)::text = 'X17'::text)
> > (2 rows)
>
> I still think you're playing games with the output. a) This is not an EXPLAIN
> ANALYZE at all, there are no "actual" values. And b) there's no explanation
> for why the estimates should be different for this query than the previous,
> identical, query.

My mistake, copy&paste error.

> Send along the actual psql session, not an edited version.

Actual session is attached.

If I may suggest it -- try to run the queries yourself.  You will find
the problem
lies not in the statistics.

   Regards,
      Dawid

Attachment

pgsql-general by date:

Previous
From: Marco Colombo
Date:
Subject: Re: Delete/update with limit
Next
From: Stephan Szabo
Date:
Subject: Re: Delete/update with limit