| 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: | 47C1B663.2060303@commandprompt.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian G. Pflug | 2008-02-24 19:07:44 | Re: Behaviour of rows containg not-null domains in plpgsql |
| Previous Message | Joshua D. Drake | 2008-02-24 18:22:48 | Re: 8.3 / 8.2.6 restore comparison |