Merlin, first of all, thanks for your reply!
hm. where exactly is all this time getting spent? Are you i/o bound?
cpu bound? Is there any compression going on?
Very good questions. pg_dump -F c compresses per default at a moderate
level (manpage), whatever compression level 'moderate'
On Mon, Mar 7, 2011 at 7:28 AM, chris r. chri...@gmx.net wrote:
Merlin, first of all, thanks for your reply!
hm. where exactly is all this time getting spent? Are you i/o bound?
cpu bound? Is there any compression going on?
Very good questions. pg_dump -F c compresses per default at a
On Mon, Mar 7, 2011 at 8:52 AM, Merlin Moncure mmonc...@gmail.com wrote:
Well, that's a pretty telling case, although I'd venture to say not
typical. In average databases, I'd expect 10-50% range of improvement
going from text-binary which is often not enough to justify the
compatibility
Dear list,
As discussed extensively in the past [1], pg_dump tends to be slow for
tables that contain bytea columns with large contents. Starting with
postgres version 8.5 the COPY format of bytea was changed from escape to
hex [1], giving ~50% performance boost.
However, we experience heavy
As discussed extensively in the past [1]
Argh, forgot to add the reference:
[1]: http://archives.postgresql.org/pgsql-hackers/2009-05/msg00192.php
Chris
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
On Wed, Mar 2, 2011 at 2:35 AM, chris r. chri...@gmx.net wrote:
Dear list,
As discussed extensively in the past [1], pg_dump tends to be slow for
tables that contain bytea columns with large contents. Starting with
postgres version 8.5 the COPY format of bytea was changed from escape to
hex
On 2 Mar 2011, at 9:35, chris r. wrote:
GB). Note that we ran VACUUM FULL on the tables affected.
Did you also REINDEX them?
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4d6e8542235882633876383!
--
Sent via pgsql-general mailing list
