content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-4"
Content-Transfer-Encoding: quoted-printable
Subject: Re: Function to either return one or all records 
Date: Thu, 21 Apr 2005 10:34:33 +0300
Message-ID: <A66A11DBF5525341AEF6B8DE39CDE7700729EC@black.aprote.com>
Thread-Topic: [SQL] Function to either return one or all records 
Thread-Index: AcVF7PM47Lyd7elTSiygL17urBbyPgAVyeJQ
From: "Tambet Matiisen" <t.matiisen@aprote.ee>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: =?iso-8859-4?Q?K=D6PFERL_Robert?= <robert.koepferl@sonorys.at>,
	<pgsql-sql@postgresql.org>


> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
> Sent: Thursday, April 21, 2005 12:06 AM
> To: Tambet Matiisen
> Cc: K=D6PFERL Robert; pgsql-sql@postgresql.org
> Subject: Re: [SQL] Function to either return one or all records=20
>=20
>=20
> "Tambet Matiisen" <t.matiisen@aprote.ee> writes:
> > Standard technique is to rewrite OR queries to UNION queries. I=20
> > believe PostgreSQL optimizer does not do that automatically. So you=20
> > could try instead:
>=20
> > select * from id_bal_tbl where $1 is null
> > union all
> > select * from id_bal_tbl where id =3D $1;
>=20
> ... but that won't do anything to solve the performance=20
> problem. Doesn't help for the second select to use an index,=20
> if the first one grovels over the whole table anyway ...
>=20

Hmm, I tought about that before sending mail to list and did a little =
test. My test indicated, that the seq scan was discarded, it was =
definitely faster than OR query. I couldn't verify plan, as EXPLAIN =
shows only function scan.

  Tambet