From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Further open item (Was: Status of 7.2) |
Date: | 2001-11-19 17:59:33 |
Message-ID: | 20011119095348.L47383-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 19 Nov 2001, Tille, Andreas wrote:
> On Fri, 16 Nov 2001, Thomas Lockhart wrote:
> > There is not much point in arguing a specific query case,
> It is no specific query case. It is the speed of an index scan which
> goes like N if you do it with PostgreSQL and it goes like log N if
> you do not have to look back into the table like MS SQL server does.
But it is in some way. It's dependant on the number of rows returned
by the query. For a small enough number of rows returned, having the
additional information in the index could very well make the query
slower even if it avoids the reads from the heap. Keeping the information
in some other fashion where it doesn't directly do that may alleviate
that, but it's not a straightforward one is better than the other in
all cases. It's not like postgres never uses an index on a large
table, it's just that after a certain amount of expected returns it
switches over.
From | Date | Subject | |
---|---|---|---|
Next Message | F Harvell | 2001-11-19 18:00:11 | Re: [HACKERS] bug or change in functionality in 7.2? |
Previous Message | Tom Lane | 2001-11-19 17:54:28 | Re: Further open item (Was: Status of 7.2) |