Re: Help speeding up delete

Поиск
Список
Период
Сортировка
От Steve Wampler
Тема Re: Help speeding up delete
Дата
Msg-id 43795E2C.4040502@noao.edu
обсуждение исходный текст
Ответ на Re: Help speeding up delete  (Scott Lamb <slamb@slamb.org>)
Список 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 по дате отправления:

Предыдущее
От: Scott Lamb
Дата:
Сообщение: Re: Help speeding up delete
Следующее
От: Claus Guttesen
Дата:
Сообщение: Re: Hardware/OS recommendations for large databases (5TB)