Skip site navigation (1) Skip section navigation (2)

AW: [INTERFACES] Re: [HACKERS] changes in 6.4

From: Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at>
To: "'maillist(at)candle(dot)pha(dot)pa(dot)us'" <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: "hackers(at)postgreSQL(dot)org" <hackers(at)postgreSQL(dot)org>
Subject: AW: [INTERFACES] Re: [HACKERS] changes in 6.4
Date: 1998-08-31 10:22:05
Message-ID: 01BDD4DA.C7F5B690@zeugswettera.user.lan.at (view raw or flat)
Thread:
Lists: pgsql-hackers
>Another idea would be to do actual UNION queries:
>
>	SELECT * FROM tab
>	WHERE (x=3 and y=4)
>	UNION
>	SELECT * FROM tab
>	WHERE (x=3 and y=5)
>	UNION
>	SELECT * FROM tab
>	WHERE (x=3 and y=6) ...
>
>This would work well for tables with indexes, but for a sequential scan,
>you are doing a sequential scan for each UNION.

The most important Application for this syntax will be M$ Access
because it uses this syntax to display x rows from a table in a particular
sort order. In this case x and y will be the primary key and therefore have a
unique index. So I think this special case should work good.

The strategy could be something like:
iff x, y is a unique index
	do the union access path
else
	do something else
done

I think hand written SQL can always be rewritten if it is not fast enough
using this syntax.

Andreas


pgsql-hackers by date

Next:From: The Hermit HackerDate: 1998-08-31 12:24:46
Subject: Re: [HACKERS] flock patch breaks things here
Previous:From: Tatsuo IshiiDate: 1998-08-31 09:15:29
Subject: LinuxPPC problems

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group