Re: 8.3 / 8.2.6 restore comparison

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:06:49
Message-ID: 47C1B239.2040105@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joshua D. Drake wrote:
> Heikki Linnakangas wrote:
>>
>> We read 64 KB at a time, and then CopyReadLineText returns one line
>> at a time from that buffer.
>
> O.k. I am sure I am oversimplifying things but why are we returning
> one line at a time? That reads expensive to me. Just following the
> general, don't do inserts one at a time, do them in batch idea for
> example.

Quite simply because one line corresponds to one record. And yes, I
believe you are oversimplifying, or under several misapprehensions about
what can be done at this level.

>
> 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.

>
> In reading:
>
> http://doxygen.postgresql.org/backend_2commands_2copy_8c-source.html
>
> It looks like CopyReadAttributesText is used as part of the column
> breakup. It also appears that this happens "before" insert right? So
> if that is the case we are going to pay an additional penalty on the
> data checking.
>

What? I don't understand what you are talking about.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-02-24 18:08:38 Re: Behaviour of rows containg not-null domains in plpgsql
Previous Message Andy Pavlo 2008-02-24 18:04:42 Re: Improved (De)Serialization Support