Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF) |
Дата | |
Msg-id | m0zP930-000EBQC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF) ("Taral" <taral@mail.utexas.edu>) |
Ответы |
Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)
|
Список | pgsql-hackers |
> > > > 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) #
В списке pgsql-hackers по дате отправления: