Re: updates (postgreSQL) very slow

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Bobbie van der Westhuizen <Bobbie(at)idpi1(dot)agric(dot)za>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: updates (postgreSQL) very slow
Date: 2004-03-11 15:00:21
Message-ID: 40507F05.8080409@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello,

Is this a place where increasing default_statistics_target will help?

Sincerely,

J

Bobbie van der Westhuizen wrote:
> On 11 Mar 2004 at 2:01, Tom Lane wrote:
>
> Fred Moyer <fred(at)redhotpenguin(dot)com> writes:
>
>>On Wed, 2004-03-10 at 15:30, Tom Lane wrote:
>>
>>>A while, sure, but 2 hours seems excessive to me too.
>
>
>>If there are no foreign keys or triggers and updating each row is taking
>>one drive seek ( approximately 9 ms with the 80 gig IDE drive being used
>>here ) then to do 747524 seeks will take 6727716 ms, about 10% less than
>>the time of 7628686 ms for the update above. Is this is an accurate
>>estimate or are these numbers just coincidence?
>
>
> Probably coincidence. There's no reason to think that a large UPDATE
> would expend one disk seek per updated row on average --- there's
> enough
> buffering between the UPDATE and the drive heads that under normal
> circumstances the cost should be lots less.
>
> If I had to bet at this point I'd bet on inefficient foreign-key checks,
> but since we haven't seen any schema details that's purely
> speculation.
>
> regards, tom lane
>
> There are no foreign-keys in this table. What schema details do you
> need, then I can give it to you. I am a new user of postgreSQL so I am
> not clude-up with all of the stuff.
> ________________________________________________________
> __
> Bobbie van der Westhuizen
> Quantitative Animal Breeding (BLUP)
> ARC - Animal Improvement Institute
> +27-12-672-9128 (o/h)
> +27-12-665-1419 (fax)
> bobbie(at)irene(dot)agric(dot)za
> ________________________________________________________
> __
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match

Attachment Content-Type Size
jd.vcf text/x-vcard 640 bytes

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2004-03-11 15:26:28 Re: updates (postgreSQL) very slow
Previous Message Peter Eisentraut 2004-03-11 14:42:23 Re: "make check" fails for 7.4.2 checked out from CVS