Re: Optimizing a condition based on an a very unequally distributed value.

From: "Nick Fankhauser" <nickf(at)ontko(dot)com>
To: "Stephan Szabo" <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: "pgsql-admin" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Optimizing a condition based on an a very unequally distributed value.
Date: 2002-03-13 19:47:42
Message-ID: NEBBLAAHGLEEPCGOBHDGEENMEIAA.nickf@ontko.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Thanks for the answer! ...but now I have more questions:

Is it true that if I use this condition in a join that further constrains
the results, this might use the index?

Does PGSQL know that few or many rows will be returned because of data
gathered from the last vacuum?

What do you mean by "tuple validity?" can't this query be resolved entirely
based on the index?

-Nick
> -----Original Message Snips:-----

> > So my question in general is why does PGSQL opt to use the index when
> > looking for the single field row, and not use it when looking
> for the other
> > 23768 rows?
>
> Because in many cases the sequence scan will be faster than an index scan
> when you're trying to get most of the rows of the table. Since the tuple
> validity is in the table row and not the index, it's still got to check
> the table which would involve lots of random reads into that file, so
> you're doing even more disk operations and less efficient ones.
>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message bangh 2002-03-13 20:40:05 Re: Update 6.5 database files to 7.0
Previous Message Stephan Szabo 2002-03-13 19:42:05 Re: Optimizing a condition based on an a very unequally