Re: updates (postgreSQL) very slow
От | Joshua D. Drake |
---|---|
Тема | Re: updates (postgreSQL) very slow |
Дата | |
Msg-id | 40507F05.8080409@commandprompt.com обсуждение исходный текст |
Ответ на | Re: updates (postgreSQL) very slow ("Bobbie van der Westhuizen" <Bobbie@irene.agric.za>) |
Список | 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@redhotpenguin.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@irene.agric.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
Вложения
В списке pgsql-general по дате отправления: