Re: [HACKERS] strange behavior of UPDATE

From: Edmund Mergl <E(dot)Mergl(at)bawue(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers Mailinglist <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] strange behavior of UPDATE
Date: 1999-05-25 05:11:12
Message-ID: 374A30F0.5DA9BCFA@bawue.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> Edmund Mergl <E(dot)Mergl(at)bawue(dot)de> writes:
> > The table is filled with 1.000.000 rows of random data
> > and on every field an index is created.
>
> BTW, do you happen to know just how random the data actually is?
> I noticed that the update query
> update bench set k500k = k500k + 1 where k100 = 30;
> updates 10,000 rows. If this "random" data actually consists of
> 10,000 repetitions of only 100 distinct values in every column,
> then a possible explanation for the problem would be that our
> btree index code isn't very fast when there are large numbers of
> identical keys. (Mind you, I have no idea if that's true or not,
> I'm just trying to think of likely trouble spots. Anyone know
> btree well enough to say whether that is likely to be a problem?)
>
> regards, tom lane

the query:

update bench set k500k = k500k + 1 where k100 = 30;

affects about 10.000 rows. This can be determined by running
the query:

select k500k from bench where k100 = 30;

which takes about half a minute. That's the reason I
was talking about the strange UPDATE behavior of
PostgreSQL. If it can determine a specific number
of rows in a reasonable time, it should be able to
update these rows in the same time frame.

Edmund

--
Edmund Mergl mailto:E(dot)Mergl(at)bawue(dot)de
Im Haldenhau 9 http://www.bawue.de/~mergl
70565 Stuttgart fon: +49 711 747503
Germany

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-05-25 05:28:34 Fix for INET 00/0
Previous Message Bruce Momjian 1999-05-25 03:57:50 INET type and 00/0