| 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: | 9646.1264264561@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-01-23 16:37:13 | pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin. |
| Previous Message | Tom Lane | 2010-01-23 16:32:37 | Re: Largeobject Access Controls (r2460) |