Tom Lane napsal(a):
Cutting a third off the size of a system index has got to be worth
something, but is it worth a hack as ugly as this one?
The problem what I see there is how to fit with in-place-upgrade. Catalog should
be generate from scratch, but if somebody uses name in regular table
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
Cutting a third off the size of a system index has got to be worth
something, but is it worth a hack as ugly as this one?
The problem what I see there is how to fit with in-place-upgrade. Catalog
should
be generate from scratch,
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
Cutting a third off the size of a system index has got to be worth
something, but is it worth a hack as ugly as this one?
The problem what I see there is how to fit with in-place-upgrade. Catalog should
be
Mark,
Not that I disagree with your change, but 5 Mbytes in 4 Gbytes of RAM
for my main PostgreSQL system that I manage seems like a drop in the
bucket. Even if 40% of pg_class_relname and pg_proc_proname indices was
saved - we're talking about 154 Kbytes saved on both those indices
dead easy to implement this: effectively, we just decree that the
index column storage type for NAME is always CSTRING. Because the
Isn't it a reason to add STORAGE option of CREATE OPERATOR CLASS to BTree? as
it's done for GiST and GIN indexes.
--
Teodor Sigaev
Mark Mielke wrote:
Not that I disagree with your change, but 5 Mbytes in 4 Gbytes of RAM
for my main PostgreSQL system that I manage seems like a drop in the
bucket. Even if 40% of pg_class_relname and pg_proc_proname indices was
saved - we're talking about 154 Kbytes saved on both those
Shane Ambler wrote:
My question is whether this is limited to system catalogs? or will this
benefit char() index used on any table? The second would make it more
worthwhile.
char(n) fields are already stored as variable-length on disk. This isn't
applicable to them.
--
Heikki Linnakangas
Teodor Sigaev [EMAIL PROTECTED] writes:
dead easy to implement this: effectively, we just decree that the
index column storage type for NAME is always CSTRING. Because the
Isn't it a reason to add STORAGE option of CREATE OPERATOR CLASS to BTree? as
it's done for GiST and GIN indexes.
Hmm
Shane Ambler wrote:
Mark Mielke wrote:
Not that I disagree with your change, but 5 Mbytes in 4 Gbytes of
RAM for my main PostgreSQL system that I manage seems like a drop in
the bucket. Even if 40% of pg_class_relname and pg_proc_proname
indices was saved - we're talking about 154 Kbytes
Josh Berkus wrote:
Shane Ambler wrote:
Mark Mielke wrote:
Not that I disagree with your change, but 5 Mbytes in 4 Gbytes of
RAM for my main PostgreSQL system that I manage seems like a drop in
the bucket. Even if 40% of pg_class_relname and pg_proc_proname
indices was saved - we're talking
Mark Mielke wrote:
saved - we're talking about 154 Kbytes saved on both those indices
combined. Minor? Major? I bet I wouldn't notice unless my database
requirements used up all RAM, and even then I'm suspecting it wouldn't
matter except for border line cases (like all pages required for
I would mention in the C comment that we are doing this for space
savings, but other than that, it seems fine.
---
Tom Lane wrote:
I was thinking a bit about how we pad columns of type NAME to
fixed-width, even though
Tom Lane wrote:
Cutting a third off the size of a system index has got to be worth
something, but is it worth a hack as ugly as this one?
I think so.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, 2008-06-23 at 15:52 -0400, Tom Lane wrote:
CVS HEADw/patch savings
pg_database_size('postgres') 4439752 4071112 8.3%
pg_relation_size('pg_class_relname_nsp_index')57344 40960
28%
Andrew Dunstan wrote:
Tom Lane wrote:
Cutting a third off the size of a system index has got to be worth
something, but is it worth a hack as ugly as this one?
I think so.
Were you able to time any speedup? Is this something that would benefit
installations with a lot of metadata? I
Mark Mielke [EMAIL PROTECTED] writes:
Tom Lane wrote:
Cutting a third off the size of a system index has got to be worth
something, but is it worth a hack as ugly as this one?
Were you able to time any speedup?
I didn't try; can you suggest any suitable benchmark?
The performance impact is
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2008-06-23 at 15:52 -0400, Tom Lane wrote:
Cutting a third off the size of a system index has got to be worth
something, but is it worth a hack as ugly as this one?
Not doing it would be more ugly, unless there is some negative
side-effect?
I
Tom Lane wrote:
Were you able to time any speedup?
I didn't try; can you suggest any suitable benchmark?
Unfortunately - no. I kind of think it won't benefit any of my databases
in any noticeable way. My numbers are similar to yours:
pccyber=# select
18 matches
Mail list logo
