Re: [HACKERS] Use of Indicies ...

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Use of Indicies ...
Date: 2000-01-24 10:03:42
Message-ID: 388C237E.709510E6@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> The Hermit Hacker <scrappy(at)hub(dot)org> writes:
> > There is an index on all three conditions in the WHERE clause:
> > Yet EXPLAIN shows:
> > Aggregate (cost=2.05 rows=1 width=4)
> -> Index Scan using referrer_link_counter_id on referrer_link (cost=2.05 rows=1 width=4)
>
> > Why does EXPLAIN only show the use of one of the indices, why counter_id
> > and why not all three?
>
> Indexscans only know how to use one index at a time.

would it make sense to implement a new (?) "join" strategy for evaluating
AND's
that gets just tids from affected indices and then performs a multiset AND on
them
sorts the result and then uses the it to access the actual rows.

>
> Do you have reason to think that one of the other indexes would have
> been cheaper?
>

It could be faster if one could actually do the above.

It's just another of these unintuitive things I mentioned in the "Happy
dropping"
thread - common sense guess of optimiser behaviour is not what it actually
done.

--------------
Hannu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeroen van Vianen 2000-01-24 10:25:38 Re: [HACKERS] Implementing STDDEV and VARIANCE
Previous Message Zeugswetter Andreas SB 2000-01-24 09:47:23 AW: [HACKERS] Some notes on optimizer cost estimates