The Hermit Hacker wrote:
>
> thanks for the pointer ... I just posted my response ... specifically
> pointing out how "accurate" the MySQL docs tend to be *rofl*
And now there is a response to your response stating the following
>
> The MySQL people have said exactly the same sort of things about
> the PostgreSQL people. So please stop the name-calling and
> the quotes around "test", it's not going to get you anywhere.
>
> That being said, the standard MySQL benchmark _still_ is 30 times
> faster for MySQL 3.23 than on PostgreSQL 7.0 (with fsync turned off,
> _and_ nonstandard speed-up PostgreSQL features like VACUUM enabled,
btw, how does one "enable" vacuum ?
> I might add). The main reason seems to be some sort of failure to
> use the index in the SELECT and UPDATE test loops on the part of
> PostgreSQL.
>
> The benchmark, for the curious, works like this:
>
> First it creates a table with an index:
>
> create table bench1 (id int NOT NULL,id2 int NOT NULL,id3 int NOT NULL,dummy1 char(30)); create unique
> index bench1_index_ on bench1 using btree (id,id2); create index bench1_index_1 on bench1 using btree (id3);
>
> Then it fills the table with 300.000 entries with unique id values.
>
> Then, it issues a query like this:
>
> update bench1 set dummy1='updated' where id=1747
>
> which causes the backend to do one thousand read() calls. For each query.
could it be that just updating 1 unique index causes 1k read()'s ?
> No wonder it's slow. An EXPLAIN query states that it's using the
> index, though. I have no clue what happens here. I've sent this
> to the pgsql-general mailing list and have just reposted it to -hackers.
I somehow missed it (on -hackers at least) so I repost it here
> Oh yes, the benchmark also revealed that CREATE TABLE in PostgreSQL 7.0
> leaks about 2k of memory.
-------------------
Hannu
