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