08, at 10:01 PM, John Huttley wrote:
Greg Smith wrote:
On Mon, 29 Sep 2008, John Huttley wrote:
checkpoint _segments=16 is fine, going to 64 made no improvement.
You might find that it does *after* increasing shared_buffers. If
the buffer cache is really small, the checkpoints can't
Scott Marlowe wrote:
On Sun, Sep 28, 2008 at 8:01 PM, John Huttley <[EMAIL PROTECTED]> wrote:
Ahh bugger, I've just trashed my test setup.
I've settled on 64Mb shared memory since I've only got 1Gb or RAM and the
system impact of 256M is severe.
Also it uses FB-DIMMS whi
Greg Smith wrote:
On Mon, 29 Sep 2008, John Huttley wrote:
checkpoint _segments=16 is fine, going to 64 made no improvement.
You might find that it does *after* increasing shared_buffers. If the
buffer cache is really small, the checkpoints can't have very much
work to do, so
Thanks to everyone that responded.
I've done some benchmarking
checkpoint _segments=16 is fine, going to 64 made no improvement.
Using "update file set size=99" as a statement, but changing 99 on each
run..
With 32M shared memory, time in sec and leaving the system idle long
enough between ru
Ahh! I've not dealt with that before. I'll look it up.
Thanks Tom.
Tom Lane wrote:
John Huttley <[EMAIL PROTECTED]> writes:
You are thinking of HOT?
I don't think it applies in the case of full table updates??
Sure, as long as there's enough free space on
Scott Marlowe wrote:
On Fri, Sep 26, 2008 at 5:03 PM, John Huttley <[EMAIL PROTECTED]> wrote:
Hi Andrew,
There are two problems.
The first is the that if there is a table with a index and an update is
performed on a non indexed field,
the index is still re indexed.
I assume yo
Hi Greg,
I've got 32M shared on a 1G machine and 16 checkpoint segments.
I'll run some tests against 64 segments and see what happens.
Your previous postings were extremely helpful wrt the MVCC issue.
I thank you!
-john
Greg Smith wrote:
On Fri, 26 Sep 2008, John Huttley wrote:
dexed field.
--even if you don't expect it.
--john
Andrew Sullivan wrote:
Hi,
On Fri, Sep 26, 2008 at 07:24:55AM +1200, John Huttley wrote:
I've just had an interesting encounter with the slow full table update
problem that is inherent with MVCC
Quite apart from the other
I've just had an interesting encounter with the slow full table update
problem that is inherent with MVCC
The system is 64 bit linux with 2.6.25 kernel feeding scsi disks.
the table is
CREATE TABLE file (
fileid integer NOT NULL,
fileindex integer DEFAULT 0 NOT NULL,
jobid integer NOT
