From: | Denis Perchine <dyp(at)perchine(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Philip Warner <pjw(at)rhyme(dot)com(dot)au>, Pavel(dot)Janik(at)linux(dot)cz, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re[2]: Re: pg_dump and LOs (another proposal) |
Date: | 2000-07-05 19:14:11 |
Message-ID: | 13120639139.20000705231411@perchine.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Tom,
Wednesday, July 05, 2000, 9:06:33 PM, you wrote:
TL> Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
>> The thing that bugs me about this if for 30,000 rows, I do 30,000 updates
>> after the restore. It seems *really* inefficient, not to mention slow.
TL> Shouldn't be a problem. For one thing, I can assure you there are no
TL> databases with 30,000 LOs in them ;-) --- the existing two-tables-per-LO
Hmmm... I have 127865 LOs at the moment. :-))) But with my patch where
all LOs are usual files on FS. I will move it to one-table-for-all-LOs
after my holidays.
TL> infrastructure won't support it. (I think Denis Perchine has started
TL> to work on a replacement one-table-for-all-LOs solution, btw.) Possibly
You can try it. I sent it to pgsql-patches some time ago.
TL> more to the point, there's no reason for pg_restore to grovel through
TL> the individual rows for itself. Having identified a column that
TL> contains (or might contain) LO OIDs, you can do something like
--
Best regards,
Denis mailto:dyp(at)perchine(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Roland Roberts | 2000-07-05 19:31:22 | Re: Per-database/schema settings |
Previous Message | Alfred Perlstein | 2000-07-05 19:14:03 | Re: proposed improvements to PostgreSQL license |