Re: Help speeding up delete - Mailing list pgsql-performance

From Steve Wampler
Subject Re: Help speeding up delete
Date
Msg-id 43795E2C.4040502@noao.edu
Whole thread Raw
In response to Re: Help speeding up delete  (Scott Lamb <slamb@slamb.org>)
List pgsql-performance
Scott Lamb wrote:
> On Nov 14, 2005, at 3:52 PM, Steve Wampler wrote:
>
>> Scott Lamb wrote:
>>
>>> On Nov 14, 2005, at 2:07 PM, Steve Wampler wrote:
>>>
>>>> # SELECT at.id FROM "tmp_table2" at, "tmp_tabl2e" a
>>>> #   WHERE at.id=a.id and a.name='obsid' and a.value='oid080505';
>>>
>>>
>>>
>>> Isn't this equivalent?
>>>
>>> select id from tmp_table2 where name = 'obsid' and value =  'oid080505';
>>
>>
>> Probably, the user based the above on a query designed to find
>> all rows with the same id as those rows that have a.name='obsid' and
>> a.value='oid080505'.
>
>
> Well, this indirection is only significant if those two sets can
> differ. If (A) you meant "tmp_table2" when you wrote "tmp_tabl2e", so
> this is a self-join, and (B) there is a primary key on "id", I don't
> think that can ever happen.

I wasn't clear.  The original query was:

   SELECT at.* FROM "tmp_table2" at, "tmp_table2" a
       WHERE at.id=a.id and a.name='obsid' and a.value='oid080505';

which is significantly different than:

   SELECT * FROM "tmp_table2" WHERE name='obsid' and value='oid080505';

The user had adapted that query for her needs, but it would have been
better to just use the query that you suggested (as the subselect in
the DELETE FROM...).  Unfortunately, that only improves performance
slightly - it is still way too slow on deletes.

--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.

pgsql-performance by date:

Previous
From: Scott Lamb
Date:
Subject: Re: Help speeding up delete
Next
From: Claus Guttesen
Date:
Subject: Re: Hardware/OS recommendations for large databases (5TB)