Date: Mon, 15 Aug 2005 03:37:41 +0200
From: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
To: pgsql-performance@postgresql.org
Subject: Re: Performance pb vs SQLServer.
Message-ID: <20050815013741.GA32106@uio.no>
Mail-Followup-To: pgsql-performance@postgresql.org
References: <20050811131911.3175A1C0031B@mwinf0401.wanadoo.fr>
	<42FFE17A.6010208@arbash-meinel.com>
	<20050815010159.GA27795@uio.no> <14401.1124068725@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <14401.1124068725@sss.pgh.pa.us>
User-Agent: Mutt/1.5.9i

On Sun, Aug 14, 2005 at 09:18:45PM -0400, Tom Lane wrote:
> Not really.  There's been some speculation about implementing index
> "skip search" --- once you've verified there's at least one visible
> row of a given index value, tell the index to skip to the next different
> value instead of handing back any of the remaining entries of the
> current value.  But it'd be a lot of work and AFAICS not useful for
> very many kinds of queries besides this.

This is probably a completely wrong way of handling it all, but could it be
done in a PL/PgSQL query like this? (Pseudo-code, sort of; I'm not very well
versed in the actual syntax, but I'd guess you get the idea.)

x = ( SELECT foo FROM table ORDER BY foo LIMIT 1 );
WHILE x IS NOT NULL
  RETURN NEXT x;
  x = ( SELECT foo FROM table WHERE foo > x ORDER BY foo LIMIT 1 );
END;

(Replace with max() and min() for 8.1, of course.)

/* Steinar */
- fond of horrible hacks :-)
-- 
Homepage: http://www.sesse.net/