Largeobject Access Controls (r2460)
in [PgSql]
|
Prev: [HACKERS] is any reason why we cannot cast from record (row) to typed row?
Next: [HACKERS] 8.5 vs. 9.0
From: "Kevin Grittner" on 25 Jan 2010 13:41 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Did you happen to notice anything about pg_dump's memory > consumption? Not directly, but I was running 'vmstat 1' throughout. Cache space dropped about 2.1 GB while it was running and popped back up to the previous level at the end. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 25 Jan 2010 14:06 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> wrote: > Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > >> Did you happen to notice anything about pg_dump's memory >> consumption? > > Not directly, but I was running 'vmstat 1' throughout. Cache > space dropped about 2.1 GB while it was running and popped back up > to the previous level at the end. I took a closer look, and there's some bad news, I think. The above numbers were from the ends of the range. I've gone back over and found that while it dropped about 2.1 GB almost immediately, cache usage slowly dropped throughout the dump, and bottomed at about 6.9 GB below baseline. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 25 Jan 2010 14:46 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> wrote: >> Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> Did you happen to notice anything about pg_dump's memory >>> consumption? > I took a closer look, and there's some bad news, I think. The above > numbers were from the ends of the range. I've gone back over and > found that while it dropped about 2.1 GB almost immediately, cache > usage slowly dropped throughout the dump, and bottomed at about 6.9 > GB below baseline. OK, that's still not very scary --- it just means my off-the-cuff estimate of 1:1 space usage was bad. 3:1 isn't that surprising either given padding and other issues. The representation of ArchiveEntries could probably be made a bit more compact ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Takahiro Itagaki on 28 Jan 2010 04:21 KaiGai Kohei <kaigai(a)ak.jp.nec.com> wrote: > The attached patch uses one TOC entry for each blob objects. When I'm testing the new patch, I found "ALTER LARGE OBJECT" command returns "ALTER LARGEOBJECT" tag. Should it be "ALTER LARGE(space)OBJECT" instead? As I remember, we had decided not to use LARGEOBJECT (without a space) in user-visible messages, right? Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 28 Jan 2010 10:31
Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes: > When I'm testing the new patch, I found "ALTER LARGE OBJECT" command > returns "ALTER LARGEOBJECT" tag. Should it be "ALTER LARGE(space)OBJECT" > instead? As I remember, we had decided not to use LARGEOBJECT > (without a space) in user-visible messages, right? The command tag should match the actual command. If the command name is "ALTER LARGE OBJECT", the command tag should be too. This is independent of phraseology we might choose in error messages (though I agree I don't like "largeobject" in those either). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |