Tom Lane wrote:
Alessandro Baretta <a.baretta@xxxxxxxxxxxxxxxxxx> writes:
I am considering the possibility of rebuilding the server with
NAMEDATALEN equal to 256. I have seen an interesting thread [1] about
the performance impact of raising NAMEDATALEN, but it did not seem
conclusive.
More to the point, tests done on 7.2-era code shouldn't be assumed to be
relevant to modern PG releases. I think you'll need to do your own
benchmarking if you want to find out the costs of doing this.
regards, tom lane
That's sensible. Now, performance in my case is much less critical than the
robustness and scalability of the application, so I guess I could just leave it
to that and go with raising namedatalen. Yet, I would like to receive some
insight on the implications of such a choice. Beside the fact that the parser
has more work to do to decipher queries and whatnot, what other parts of the
server would be stressed by a verbose naming scheme? Where should I expect the
bottlenecks to be?
Also, I could imagine a solution where I split the names in a schema part and a
local name, thereby refactoring my namespace. I'd get the approximate effect of
doubling namedatalen, but at the expense of having a much wider searchpath.
Based on your experience, which of two possible strategies is more prone to
cause trouble?
Alex
--
*********************************************************************
Ing. Alessandro Baretta
Studio Baretta
http://studio.baretta.com/
Consulenza Tecnologica e Ingegneria Industriale
Technological Consulting and Industrial Engineering
Headquarters
tel. +39 02 370 111 55
fax. +39 02 370 111 54
Lab
tel. +39 02 9880 271
fax. +39 02 9828 0296
