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: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Largeobject Access Controls (r2460)
Date: 2010-01-23 16:36:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> writes:
> (2010/01/23 5:12), Tom Lane wrote:
>> Now the argument against that is that it won't scale terribly well
>> to situations with very large numbers of blobs.

> Even if the database contains massive number of large objects, all the
> pg_dump has to manege on RAM is its metadata, not data contents.

I'm not so worried about the amount of RAM needed as whether pg_dump's
internal algorithms will scale to large numbers of TOC entries.  Any
O(N^2) behavior would be pretty painful, for example.  No doubt we could
fix any such problems, but it might take more work than we want to do
right now.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-01-23 16:37:13
Subject: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.
Previous:From: Tom LaneDate: 2010-01-23 16:32:37
Subject: Re: Largeobject Access Controls (r2460)

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