Re: Index not being used in MAX function (7.2.3) - Mailing list pgsql-general

From Bruno Wolff III
Subject Re: Index not being used in MAX function (7.2.3)
Date
Msg-id 20030614154100.GA29302@wolff.to
Whole thread Raw
In response to Re: Index not being used in MAX function (7.2.3)  ("Jim C. Nasby" <jim@nasby.net>)
Responses Re: Index not being used in MAX function (7.2.3)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Sat, Jun 14, 2003 at 10:23:20 -0500,
  "Jim C. Nasby" <jim@nasby.net> wrote:
>
> It would be useful if we didn't have to immediately consider MVCC info,
> which requires hitting the tupples. Indexes are usually much narrower
> than tables, even with metadata included, so you can scan two indexes
> and and/or the results faster than scanning one index, then hitting all
> the tuples.

I don't think you are likely to see much gain from this as scanning
two indexes instead of one is likely to cost about as much as scanning
an index and looking at the tupples to see if they match the other
condition. Also if you look at both indexes you have to do a join
to connect the tuples back together and there is going to be some
cost to that.
>
> What indexes are on crate?

I had indexes on areaid, game and game, areaid. I created one of crate
for the test. I don't normally search on crate. I do do orders on it,
but generally after joins so an index isn't a great help. The table only
has about 16000 rows in it, so it is a pretty small sample.

I would actually be interested in hearing a comment from someone who
knows more just how a index condition with an OR is handled when the
two indexes aren't part of the same multicolumn index.

pgsql-general by date:

Previous
From: Sven Köhler
Date:
Subject: Re: full featured alter table?
Next
From: Guillaume LELARGE
Date:
Subject: Re: full featured alter table?