Thread: Re: [BUGS] Prepared Statement Name Truncation
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Gavin Flower asks: > Would it be appropriate to make it a WARNING in 9.2.2, then > increase the length in 9.3? No: revisions are reserved for bug fixes. This would be more of a behavior fix and as such would go into a major version. Gavan Schneider wrote: > (Wild speculation) There may be a "sweet spot" using even shorter > identifiers than is the case now, with full disambiguation, which > might improve overall performance. I really don't think the length is really a bottleneck, but others can correct me if it is. Tom Lane wrote: > There's some possible value in having a non-default option to throw > error for overlength names, but TBH I fear that it won't buy all that > much, because people won't think to turn it on when testing. > > Given the historical volume of complaints (to wit, none up to now), > I can't get very excited about changing the behavior here. I think > we're more likely to annoy users than accomplish anything useful. Well, as with many other things, a lack of complaints does not indicate there is no problem. I've certainly seen this problem in the wild before, but have not bothered to file an official bug report or anything. Perhaps my bad, but the problem is out there. How would you feel about switching from NOTICE to WARNING, Tom? That seems to make a lot more sense as we are changing the user's input, which warrants more than a notice IMO. Separately, what are the objections to raising the size limit to 128? - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201211211525 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlCtOYMACgkQvJuQZxSWSsjmEQCfb6GOEs7jwst1ao70L+j8IW5q gNYAn110QAhwjuhUSW3/uexvU+StsfZz =iw6q -----END PGP SIGNATURE-----
2012/11/21 Greg Sabino Mullane <greg@turnstep.com>: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > Gavin Flower asks: > >> Would it be appropriate to make it a WARNING in 9.2.2, then >> increase the length in 9.3? > > No: revisions are reserved for bug fixes. This would be more of > a behavior fix and as such would go into a major version. > > Gavan Schneider wrote: >> (Wild speculation) There may be a "sweet spot" using even shorter >> identifiers than is the case now, with full disambiguation, which >> might improve overall performance. > > I really don't think the length is really a bottleneck, but others > can correct me if it is. > > Tom Lane wrote: >> There's some possible value in having a non-default option to throw >> error for overlength names, but TBH I fear that it won't buy all that >> much, because people won't think to turn it on when testing. >> >> Given the historical volume of complaints (to wit, none up to now), >> I can't get very excited about changing the behavior here. I think >> we're more likely to annoy users than accomplish anything useful. > > Well, as with many other things, a lack of complaints does not indicate > there is no problem. I've certainly seen this problem in the wild before, > but have not bothered to file an official bug report or anything. Perhaps > my bad, but the problem is out there. How would you feel about switching > from NOTICE to WARNING, Tom? That seems to make a lot more sense as we > are changing the user's input, which warrants more than a notice IMO. > > Separately, what are the objections to raising the size limit to 128? significantly larger catalog Pavel > > - -- > Greg Sabino Mullane greg@turnstep.com > End Point Corporation http://www.endpoint.com/ > PGP Key: 0x14964AC8 201211211525 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > -----BEGIN PGP SIGNATURE----- > > iEYEAREDAAYFAlCtOYMACgkQvJuQZxSWSsjmEQCfb6GOEs7jwst1ao70L+j8IW5q > gNYAn110QAhwjuhUSW3/uexvU+StsfZz > =iw6q > -----END PGP SIGNATURE----- > > > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs
On 22-11-2012 04:27, Pavel Stehule wrote: > 2012/11/21 Greg Sabino Mullane <greg@turnstep.com>: Separately, what are > the objections to raising the size limit to 128? > >> significantly larger catalog > Less than 5% of catalog columns? I don't buy your argument. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
2012/11/23 Euler Taveira <euler@timbira.com>: > On 22-11-2012 04:27, Pavel Stehule wrote: >> 2012/11/21 Greg Sabino Mullane <greg@turnstep.com>: Separately, what are >> the objections to raising the size limit to 128? >> >>> significantly larger catalog >> > Less than 5% of catalog columns? I don't buy your argument. default 6201kB (64) updated 6967kB (128) on empty database - so it is 12% more per one database in our warehouses we have more than 100000 relations per database and about 1000 databases per warehouse - so these number can be significantly higher second issue can be increasing memory allocations for system caches and some other place Regards Pavel > > > -- > Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ > PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Euler Taveira <euler@timbira.com> 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
On 23.11.2012 17:53, Tom Lane wrote: > Euler Taveira<euler@timbira.com> 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
Heikki Linnakangas <hlinnakangas@vmware.com> 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