Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF) |
Дата | |
Msg-id | 199810021740.NAA15196@candle.pha.pa.us обсуждение исходный текст |
Ответ на | RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF) ("Taral" <taral@mail.utexas.edu>) |
Список | pgsql-hackers |
[Charset iso-8859-1 unsupported, filtering to ASCII...] > > > 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? I certainly think we are heading in the direction for a good general solution. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-hackers по дате отправления: