Re: Index of a table is not used (in any case)

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "mlw" <markw(at)mohawksoft(dot)com>, "Doug McNaught" <doug(at)wireboard(dot)com>
Cc: "Reiner Dassing" <dassing(at)wettzell(dot)ifag(dot)de>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index of a table is not used (in any case)
Date: 2001-10-24 10:10:30
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA41EB3D4@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > > *very* slow, due to seq scan on
> > > 20 million entries, which is a test setup up to now)
> >
> > Perennial first question: did you VACUUM ANALYZE?
>
> Can there, or could there, be a notion of "rule based" optimization of
> queries in PostgreSQL? The "not using index" problem is probably the
most
> common and most misunderstood problem.

There is a (sort of) rule based behavior in PostgreSQL,
the down side of the current implementation is, that certain
other commands than ANALYZE (e.g. "create index") partly update
optimizer statistics. This is bad behavior, since then only part
of the statistics are accurate. Statistics always have to be seen
in context to other table's and other index'es statistics.

Thus, currently the rule based optimizer only works if you create
the indexes on empty tables (before loading data), which obviously
has downsides. Else you have no choice but to ANALYZE frequently.

I have tried hard to fight for this pseudo rule based behavior,
but was only partly successful in convincing core. My opinion is,
that (unless runtime statistics are kept) no other command than
ANALYZE should be allowed to touch optimizer relevant statistics
(maybe unless explicitly told to).

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bill Studenmund 2001-10-24 10:16:22 Re: Proposed new create command, CREATE OPERATOR CLASS
Previous Message mario 2001-10-24 09:11:03 Make a copy of a large object