Re: [HACKERS] What about LIMIT in SELECT ?

From: jwieck(at)debis(dot)com (Jan Wieck)
To: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Cc: lockhart(at)alumni(dot)caltech(dot)edu, jwieck(at)debis(dot)com, eric(at)linux-hw(dot)com, jeff(at)remapcorp(dot)com, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] What about LIMIT in SELECT ?
Date: 1998-10-14 17:57:27
Message-ID: m0zTVAt-000EBRC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

> But, you are correct that certain cases where in index is already being
> used on a query, you could just skip the sort IF you used the index to
> get the rows from the base table.

Especially in the case where

SELECT ... WHERE key > 'val' ORDER BY key;

creates a Sort->IndexScan plan. The index scan already jumps
around on the disc to collect the sorts input and the sort
finally returns exactly the same output (if the used index is
only on key).

And this is the case for large tables. The planner first
decides to use an index scan due to the WHERE clause and
later it notices the ORDER BY clause and creates a sort over
the scan.

I'm actually hacking around on it to see what happens if I
suppress the sort node in some cases.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Bruce Momjian 1998-10-14 18:01:49 Re: [HACKERS] What about LIMIT in SELECT ?
Previous Message Taral 1998-10-14 17:56:00 RE: [HACKERS] What about LIMIT in SELECT ?

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-10-14 17:59:41 Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
Previous Message Taral 1998-10-14 17:56:00 RE: [HACKERS] What about LIMIT in SELECT ?