Re: [GENERAL] [BUGS] Prepared Statement Name Truncation
Heikki Linnakangas writes: > On 23.11.2012 17:53, Tom Lane wrote: >> We could avoid this problem if we were prepared to make type "name" >> be varlena, ... > It would actually be nice to do that because it would *reduce* the > amount of space and memory used for the catalogs in the typical case, Agreed, that would be a nicer place to be ... but the amount of work required to get there is daunting, and rather out of proportion to the benefit IMO. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [GENERAL] [BUGS] Prepared Statement Name Truncation
On 23.11.2012 17:53, Tom Lane wrote: Euler Taveira writes: On 22-11-2012 04:27, Pavel Stehule wrote: significantly larger catalog Less than 5% of catalog columns? I don't buy your argument. It's not about count, it's about size. For instance, pg_attribute currently requires 140 bytes per row (counting the tuple header and line pointer), so adding 64 bytes would represent 45% bloat. In a database with lots of tables that would be painful. We could avoid this problem if we were prepared to make type "name" be varlena, ... It would actually be nice to do that because it would *reduce* the amount of space and memory used for the catalogs in the typical case, where the attribute names are much smaller than 64 bytes. I received a complaint just the other day that our backend processes consume a lot of memory, even when idle; the catalog caches are a large part of that. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [GENERAL] [BUGS] Prepared Statement Name Truncation
Euler Taveira writes: > On 22-11-2012 04:27, Pavel Stehule wrote: >>> significantly larger catalog > Less than 5% of catalog columns? I don't buy your argument. It's not about count, it's about size. For instance, pg_attribute currently requires 140 bytes per row (counting the tuple header and line pointer), so adding 64 bytes would represent 45% bloat. In a database with lots of tables that would be painful. We could avoid this problem if we were prepared to make type "name" be varlena, but that would be rather catastrophic because of the code's habit of overlaying C structures onto catalog rows. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [GENERAL] [BUGS] Prepared Statement Name Truncation
On Nov 18, 2012, at 2:24, Tom Lane wrote: > "Greg Sabino Mullane" writes: >>> If it's a postgres bug, what is the fix? Make the identifier max size >>> longer? > >> I'd also be in favor of this, in addition to upgrading from a NOTICE. > > On the whole I'm not too excited about changing this. > Then I'd agree with the OP and think the notice should go away on usage in DML; though it should be kept for DDL. Can the system be made smart enough to not allow intra-schema collisions in addition to same schema ones? That would seem to be the area of greatest concern - particularly around the usage of truncate/delete/drop. Thought: would there be some way to flag a table like this to always require the use of a schema prefix to be accessed (since right now truncated names only have to be schema unique) in certain conditions (drop, delete, truncate)? David J. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [GENERAL] [BUGS] Prepared Statement Name Truncation
"Greg Sabino Mullane" writes: >> If it's a postgres bug, what is the fix? Make the identifier max size >> longer? > I'd also be in favor of this, in addition to upgrading from a NOTICE. Increasing NAMEDATALEN has been discussed, and rejected, before. It is very very far from being a free change: it would double the storage space required for "name" columns, which is a sizable fraction of the space eaten in the pg_class and pg_attribute catalogs. (Or we could convert "name" to a variable length type, but the fallout from that would vastly exceed what this feature seems worth.) I think there probably is some case for treating overlength names as errors not warnings, but on the other hand there's a case for fearing this will break applications that work fine today. In particular, it would break applications that expect to be able to use spec-compliant 128-character names, *whether or not they actually have any collisions*. That seems pretty undesirable, especially in view of the fact that duplicate-name checks would catch any actual collisions in most cases. Another point here is that appealing to the letter of the spec in this area is a bit dubious anyway given the number of ways in which we vary from exact spec compliance --- notably, allowing non-ASCII characters in identifiers, allowing dollar signs, allowing leading underscore (no, that's not per spec), folding to lower case not upper case. On the whole I'm not too excited about changing this. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
