Tom Lane, 19.07.2012 16:52:
If you're using a reasonably recent version of PG, replacing the NOT IN
by a NOT EXISTS test should also help.
Thanks. I wasn't aware of that (and the NOT EXISTS does indeed produce the same
plan as the OUTER JOIN solution)
Now I was wondering if a DELETE stateme
On Thu, Jul 19, 2012 at 6:52 PM, Tom Lane wrote:
>> Now I was wondering if a DELETE statement could be rewritten with the same
>> "strategy":
>
> Not at the moment. There have been discussions of allowing the same
> table name to be respecified in USING, but there are complications.
However it
Sergey Konoplev, 20.07.2012 10:21:
On Thu, Jul 19, 2012 at 6:52 PM, Tom Lane wrote:
Now I was wondering if a DELETE statement could be rewritten with the same
"strategy":
Not at the moment. There have been discussions of allowing the same
table name to be respecified in USING, but there are
On Fri, Jul 20, 2012 at 2:27 PM, Thomas Kellerer wrote:
Now I was wondering if a DELETE statement could be rewritten with the
same "strategy":
>>>
>>> Not at the moment. There have been discussions of allowing the same
>>> table name to be respecified in USING, but there are complicatio
Sergey Konoplev writes:
> On Thu, Jul 19, 2012 at 6:52 PM, Tom Lane wrote:
>>> Now I was wondering if a DELETE statement could be rewritten with the same
>>> "strategy":
>> Not at the moment. There have been discussions of allowing the same
>> table name to be respecified in USING, but there a
On Fri, Jul 20, 2012 at 5:51 PM, Tom Lane wrote:
>> DELETE FROM some_table USING some_table AS s
>> WHERE
>> some_table.col1 = s.col1 AND
>> some_table.col2 = s.col2 AND
>> some_table.id < s.id;
>
> No, that's a self-join, which isn't what the OP wanted. You can make it
> work if you
