From: asif ali <asif_icrossing@yahoo.com>
To: Arnaud Lesauvage <thewild@freesurf.fr>
To: Ragnar <gnari@hive.is>
Cc: Jens Schipkowski <jens.schipkowski@apus.co.at>
Cc: pgsql-performance@postgresql.org
Subject: Re: Slow update with simple query
Date: Wed, 13 Dec 2006 08:43:57 -0800 (PST)
Message-ID: <192027.84308.qm@web58405.mail.re3.yahoo.com> (raw)
In-Reply-To: <45801A1B.6070200@freesurf.fr>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: asif_icrossing@yahoo.com, thewild@freesurf.fr, gnari@hive.is, jens.schipkowski@apus.co.at
Subject: Re: Slow update with simple query
In-Reply-To: <192027.84308.qm@web58405.mail.re3.yahoo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox