Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 6D42D9F9F46 for ; Wed, 13 Dec 2006 12:44:19 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 99011-02-2 for ; Wed, 13 Dec 2006 12:43:59 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from web58405.mail.re3.yahoo.com (web58405.mail.re3.yahoo.com [68.142.236.173]) by postgresql.org (Postfix) with SMTP id DFA499FA248 for ; Wed, 13 Dec 2006 12:43:58 -0400 (AST) Received: (qmail 84653 invoked by uid 60001); 13 Dec 2006 16:43:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=g76us8vewogst1sIf/4YVsT/sO+DJkjsiolr/NW4F4Qt4OCrIsLwoLd2j8Jp/A8Du0OVvzi6REdOP9qzPiq/ir7C3dnitkc5yrorRUyjJxTpLqs91rpIDRiiECornBG5OqvwFg/VPC+WbTzvaQ+BiSGNSpBHq2ThAyk/xsfK8Ko=; X-YMail-OSG: JQfaTZMVM1lcKZKp_aW7Z0gp3p8GFYa2s0kEQWTA Received: from [65.218.233.130] by web58405.mail.re3.yahoo.com via HTTP; Wed, 13 Dec 2006 08:43:57 PST Date: Wed, 13 Dec 2006 08:43:57 -0800 (PST) From: asif ali Subject: Re: Slow update with simple query To: Arnaud Lesauvage , Ragnar Cc: Jens Schipkowski , pgsql-performance@postgresql.org In-Reply-To: <45801A1B.6070200@freesurf.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1967235396-1166028237=:84308" Content-Transfer-Encoding: 8bit Message-ID: <192027.84308.qm@web58405.mail.re3.yahoo.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/323 X-Sequence-Number: 22379 --0-1967235396-1166028237=:84308 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Arnaud, Have you run "ANALYZE" on the table after creating index? Also make sure that "#effective_cache_size" is set properly. A higher value makes it more likely to use index scans. Thanks asif ali Arnaud Lesauvage wrote: Ragnar a écrit : > On mið, 2006-12-13 at 14:38 +0100, Arnaud Lesauvage wrote: >> Jens Schipkowski a écrit : >> > On Wed, 13 Dec 2006 13:23:41 +0100, Arnaud Lesauvage >> >> Why is this query better than the other one ? Because it runs the >> >> "(field IN ('some','other') AND field2 = 'Y')" once and then executes >> >> the join with the resulting set ? >> > True. The Subselect in FROM clause will be executed once and will be >> > joined using the condition at where clause. So your condition at t2 is not >> > executed for each row in t1(2mio records) but for each row in t2(1k >> > records). And the boolean value is already set during update. >> >> OK Jens, thanks for clarifying this. >> I thought the planner could guess what to do in such cases. > > don't worry, it will. > this is not your problem Indeed, the new query does not perform that well : "Hash Join (cost=112.75..307504.97 rows=2024869 width=355) (actual time=53.995..246443.811 rows=2020061 loops=1)" " Hash Cond: ("outer".uid = "inner".uid)" " -> Seq Scan on t1 (cost=0.00..261792.01 rows=2033001 width=338) (actual time=19.342..234304.499 rows=2033001 loops=1)" " -> Hash (cost=110.20..110.20 rows=1020 width=53) (actual time=4.853..4.853 rows=1020 loops=1)" " -> Seq Scan on t2 (cost=0.00..110.20 rows=1020 width=53) (actual time=0.017..2.586 rows=1020 loops=1)" "Total runtime: 2777844.892 ms" I removed all unnecessary indexes on t1 before running the query (I left the index on uid and the multicolumn index containind the updated field). I believe the multicolumn-functional-index computation is taking some time here, isn't it ? Regards -- Arnaud ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate --------------------------------- Any questions? Get answers on any topic at Yahoo! Answers. Try it now. --0-1967235396-1166028237=:84308 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Arnaud,
Have you run "ANALYZE" on the table after creating index?
Also make sure that "#effective_cache_size" is set properly. A higher value makes it more likely to use index scans.

Thanks
asif ali

Arnaud Lesauvage <thewild@freesurf.fr> wrote:
Ragnar a écrit :
> On mið, 2006-12-13 at 14:38 +0100, Arnaud Lesauvage wrote:
>> Jens Schipkowski a écrit :
>> > On Wed, 13 Dec 2006 13:23:41 +0100, Arnaud Lesauvage
>> >> Why is this query better than the other one ? Because it runs the
>> >> "(field IN ('some','other') AND field2 = 'Y')" once and then executes
>> >> the join with the resulting set ?
>> > True. The Subselect in FROM clause will be executed once and will be
>> > joined using the condition at where clause. So your condition at t2 is not
>> > executed for each row in t1(2mio records) but for each row in t2(1k
>> > records). And the boolean value is already set during update.
>>
>> OK Jens, thanks for clarifying this.
>> I thought the planner could guess what to do in such cases.
>
> don't worry, it will.
> this is not your problem

Indeed, the new query does not perform that well :

"Hash Join (cost=112.75..307504.97 rows=2024869 width=355) (actual time=53.995..246443.811 rows=2020061 loops=1)"
" Hash Cond: ("outer".uid = "inner".uid)"
" -> Seq Scan on t1 (cost=0.00..261792.01 rows=2033001 width=338) (actual time=19.342..234304.499 rows=2033001 loops=1)"
" -> Hash (cost=110.20..110.20 rows=1020 width=53) (actual time=4.853..4.853 rows=1020 loops=1)"
" -> Seq Scan on t2 (cost=0.00..110.20 rows=1020 width=53) (actual time=0.017..2.586 rows=1020 loops=1)"
"Total runtime: 2777844.892 ms"

I removed all unnecessary indexes on t1 before running the query (I left the index on uid and the multicolumn index containind the updated field).
I believe the multicolumn-functional-index computation is taking some time here, isn't it ?

Regards
--
Arnaud

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Any questions? Get answers on any topic at Yahoo! Answers. Try it now. --0-1967235396-1166028237=:84308--