| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Richard Huxton <dev(at)archonet(dot)com> |
| Cc: | firerox(at)centrum(dot)cz, tv(at)fuzzy(dot)cz, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: slow full table update |
| Date: | 2008-11-12 20:54:08 |
| Message-ID: | 20663.1226523248@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Richard Huxton <dev(at)archonet(dot)com> writes:
> firerox(at)centrum(dot)cz wrote:
>> I try explain query with this result
>> for 10.000 rows > update songs set views = 0 where sid > 20000 and sid < 30000
>>
>> Bitmap Heap Scan on songs (cost=151.59..6814.29 rows=8931 width=526) (actual time=4.848..167.855 rows=8945 loops=1)
> This query says t is taking 167 milli-seconds, not 10 minutes as your
> first message said. Is this query actually slow?
The explain plan tree only shows the time to fetch/compute the new rows,
not to actually perform the update, update indexes, or fire triggers.
If there is a big discrepancy then the extra time must be going into
one of those steps.
8.1 does show trigger execution time separately, so the most obvious
problem (unindexed foreign key reference) seems to be excluded, unless
the OP just snipped that part of the output ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2008-11-12 20:55:52 | Re: slow full table update |
| Previous Message | Andrus | 2008-11-12 19:57:06 | Re: Increasing select max(datecol) from bilkaib wheredatecol<=date'2008-11-01' and (cr='00' or db='00') speed |