From: | Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at> |
---|---|
To: | "'Jan Wieck'" <jwieck(at)debis(dot)com> |
Cc: | "hackers(at)postgreSQL(dot)org" <hackers(at)postgreSQL(dot)org> |
Subject: | Re: order by and index path |
Date: | 1998-10-15 08:56:50 |
Message-ID: | 01BDF82A.C7968FD0@zeugswettera.user.lan.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jan wrote:
> If there is an ORDER BY clause, using an index scan is the
> clever way if the indexqual dramatically reduces the the
> amount of data selected and sorted. I think this is the
> normal case
yes
> (who really selects nearly all rows from a 5M row
> table?).
Data Warehouse apps
> This will hurt if someone really selects most of the rows and the index
> scan jumps over the disc.
I think this is a non issue, since if a qual is not restrictive enough,
the optimizer should choose a seq scan anyway. Doesn' t it do this already ?
> But here the programmer should use
> an unqualified query to perform a seqscan and do the
> qualification in the frontend application.
I would reformulate this to:
Here the backend should do a seq scan and use the qualification to eliminate
not wanted rows.
Resumee:
You have to look at this from the cost point of view. If there is an order by that can be
done with an index, this will make the index a little more preferrable than for the same
query without the order by, but it should not force the index.
You have to give the sort a cost, so that the index access can be compared to the
seq scan and sort path.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 1998-10-15 09:56:50 | Re: [HACKERS] postmaster locking issues. |
Previous Message | Marc G. Fournier | 1998-10-15 08:39:07 | PostgreSQL v6.4 BETA2... |