Re: NAMEDATALEN and performance

Tom Lane wrote:
> Alessandro Baretta <a(dot)baretta(at)studio(dot)baretta(dot)com> 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