>
> > > Create a temporary oid hash? (for each table selected on, I guess)
> >
> > What I did with indexes was to run the previous OR clause index
> > restrictions through the qualification code, and make sure it failed,
> > but I am not sure how that is going to work with a more complex WHERE
> > clause. Perhaps I need to restrict this to just simple cases of
> > constants, which are easy to pick out an run through. Doing this with
> > joins would be very hard, I think.
>
> Actually, I was thinking more of an index of returned rows... After each
> subquery, the backend would check each row to see if it was already in the
> index... Simple duplicate check, in other words. Of course, I don't know how
> well this would behave with large tables being returned...
>
> Anyone else have some ideas they want to throw in?
>
> Taral
>
But what about unions of join queries? Which OID's then should
be checked against which? And unions from view selects? There
are no OID's at all after rewriting.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
