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
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

Browse pgsql-hackers by date

  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