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

Re: Largeobject Access Controls (r2460)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Greg Smith" <greg(at)2ndquadrant(dot)com>, "KaiGai Kohei" <kaigai(at)ak(dot)jp(dot)nec(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "KaiGai Kohei" <kaigai(at)kaigai(dot)gr(dot)jp>, "Takahiro Itagaki" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, "Jaime Casanova" <jcasanov(at)systemguards(dot)com(dot)ec>
Subject: Re: Largeobject Access Controls (r2460)
Date: 2010-01-25 18:24:23
Message-ID: 24518.1264443863@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote: 
>> It might be better to try a test case with lighter-weight objects,
>> say 5 million simple functions.
 
> Said dump ran in about 45 minutes with no obvious stalls or
> problems.  The 2.2 GB database dumped to a 1.1 GB text file, which
> was a little bit of a surprise.

Did you happen to notice anything about pg_dump's memory consumption?
For an all-DDL case like this, I'd sort of expect the memory usage to
be comparable to the output file size.

Anyway this seems to suggest that we don't have any huge problem with
large numbers of archive TOC objects, so the next step probably is to
look at how big a code change it would be to switch over to
TOC-per-blob.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-25 18:31:01
Subject: Re: Fwd: Questions about connection clean-up and "invalid page header"
Previous:From: Robert HaasDate: 2010-01-25 18:19:54
Subject: Re: MySQL-ism help patch for psql

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