Re: Performance (was: The New Slashdot Setup (includes MySql server)) - Mailing list pgsql-hackers

From Matthias Urlichs
Subject Re: Performance (was: The New Slashdot Setup (includes MySql server))
Date
Msg-id 20000519121803.M27730@noris.de
Whole thread Raw
In response to Re: Performance (was: The New Slashdot Setup (includes MySql server))  (Chris <chris@bitmead.com>)
Responses RE: Performance (was: The New Slashdot Setup (includes MySql server))
List pgsql-hackers
Hi,

Chris:
> VACUUM is not a speed-up feature, it's a slow-down feature. It reclaims
> space and that takes time. It does update system statistics which can
> help performance if done after a data load or perhaps once a day.
> 
OK, thanks for the clarification.

> But "sprinkling the code" with vacuum sounds like a big performance
> killer. Hope you are not counting vacuum as part of your 1000 read()
> calls.
> 
Nonono, the 1000 read() calls are triggered by a simple INSERT or UPDATE
call. They actually scan the pg_index table of the benchmark database. 

Why they do that is another question entirely. (a) these tables should
have indices, and (b) whatever postgres wants to know should have been
cached someplace. Oh yes, (c) what's in pg_index that needs to be 4
MBytes big?

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.       |        http://smurf.noris.de/
-- 
Man is the only animal that laughs and weeps; for he is
the only animal that is struck with the difference between
what things are and what they ought to be.                       -- William Hazlitt (1778-1830)


pgsql-hackers by date:

Previous
From: "Matthias Urlichs"
Date:
Subject: Re: Re: Heaps of read() syscalls by the postmaster
Next
From: Chris
Date:
Subject: Re: Performance (was: The New Slashdot Setup (includes MySql server))