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 gene
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
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
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
combine
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
>e
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
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 sa
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.
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
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 ind
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
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 pg_database_size('postgres');
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-effec
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
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 pr
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%
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:
http://www.p
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 th
I was thinking a bit about how we pad columns of type NAME to
fixed-width, even though they're semantically equivalent to C strings.
The reason for wasting that space is that it makes it possible to
overlay a C struct onto the leading columns of most system catalogs.
I don't wish to propose changin
19 matches
Mail list logo
