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.
>
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 |