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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1998-08-31 12:24:46 | Re: [HACKERS] flock patch breaks things here |
Previous Message | Tatsuo Ishii | 1998-08-31 09:15:29 | LinuxPPC problems |