Skip site navigation (1) Skip section navigation (2)

Re: 8.3 / 8.2.6 restore comparison

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Luke Lonergan <llonergan(at)greenplum(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.3 / 8.2.6 restore comparison
Date: 2008-02-24 18:24:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> Joshua D. Drake wrote:
>>> I would also question the 64KB at a time. Why not a 1024KB (arbitrary) 
>>> at a time? Is it a resource issue? In the old days when we actually 
>>> had people trying to run postgresql on 128 and 256 megs of ram, o.k. 
>>> but now?
>> It would be simple enough to change. Try it and see if it actually makes 
>> a difference. All you have to change is the define of RAW_BUF_SIZE.
> Seems unlikely that making it bigger than (a fraction of) L2 cache
> would be a smart move.

O.k. these CPUs have 1meg of L2 so I will try with 512k.

Joshua D. Drake

> 			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Florian G. PflugDate: 2008-02-24 19:07:44
Subject: Re: Behaviour of rows containg not-null domains in plpgsql
Previous:From: Joshua D. DrakeDate: 2008-02-24 18:22:48
Subject: Re: 8.3 / 8.2.6 restore comparison

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group