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 |
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 |