Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)

Jan Wieck <jwieck@debis.com>

From: jwieck@debis.com (Jan Wieck)
To: taral@mail.utexas.edu (Taral)
Cc: maillist@candle.pha.pa.us, hackers@postgreSQL.org
Date: 1998-10-02T17:31:18Z
Lists: pgsql-hackers, pgsql-general
> 
> > > 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) #