From: | Scott Lamb <slamb(at)slamb(dot)org> |
---|---|
To: | Steve Wampler <swampler(at)noao(dot)edu> |
Cc: | Postgres-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Help speeding up delete |
Date: | 2005-11-15 01:08:03 |
Message-ID: | CA179264-613A-4A4C-8150-0A3DC6E1890C@slamb.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance pgsql-www |
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.
> It appears (to me) to be the Seq Scan on tmp_table2
> that is the killer here. If we put an index on, would it help?
On...tmp_table2.id? If it is a primary key, there already is one. If
not, yeah, I expect it would help.
--
Scott Lamb <http://www.slamb.org/>
From | Date | Subject | |
---|---|---|---|
Next Message | Leigh Dyer | 2005-11-15 01:18:48 | Re: Help speeding up delete |
Previous Message | Steve Wampler | 2005-11-15 00:28:19 | Re: Help speeding up delete |
From | Date | Subject | |
---|---|---|---|
Next Message | Leigh Dyer | 2005-11-15 01:18:48 | Re: Help speeding up delete |
Previous Message | Steve Wampler | 2005-11-15 00:28:19 | Re: Help speeding up delete |