Re: insert ... delete ... returning ... ?
От | Mark Mielke |
---|---|
Тема | Re: insert ... delete ... returning ... ? |
Дата | |
Msg-id | 47C2033E.5040305@mark.mielke.cc обсуждение исходный текст |
Ответ на | Re: insert ... delete ... returning ... ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: insert ... delete ... returning ... ?
|
Список | pgsql-hackers |
Tom Lane wrote: <blockquote cite="mid:8368.1203893092@sss.pgh.pa.us" type="cite"><pre wrap="">"Jonah H. Harris" <a class="moz-txt-link-rfc2396E"href="mailto:jonah.harris@gmail.com"><jonah.harris@gmail.com></a> writes: </pre><blockquotetype="cite"><pre wrap="">Not stupid, it doesn't work :) This was a limitation of the original design based on (IIRC) executor-related issues. </pre></blockquote><pre wrap=""> There are definitional issues not only implementation ones; in particular, in subquery-like cases it's entirely unclear how many times the DML operation will or should get evaluated. </pre></blockquote><br /> Interesting. Would it be cheating to only allowit in cases where the evaluation should definately be only once? For example, insert ... delete, create table ... delete,or part of a join expression?<br /><br /> In any case - I don't have the know how to fix it, and it's certainly moreof a "would be cute" than "I must have it." I'll settle with my table locks for now. It's no big deal for my application.<br/><br /> I'm noticing a massive reduction in on disk storage required for my database that I believe is primarilyattributable due to Tom's reduced overhead for short strings. Some of the tables I am importing have a 10 - 20 shortstring fields (many 0 length strings!). Unfortunately - I wasn't looking for this specifically, so I didn't keep myold database instance around. But I'm thinking by memory that the biggest table is now 1/3 the number of relpages in 8.3as it was in 8.2. Good job all around hackers. Again - *NO* problems. It just works.<br /><br /> Cheers,<br /> mark<br/><br /><pre class="moz-signature" cols="72">-- Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a> </pre>
В списке pgsql-hackers по дате отправления: