Re: FUNC_MAX_ARGS benchmarks
От | Hannu Krosing |
---|---|
Тема | Re: FUNC_MAX_ARGS benchmarks |
Дата | |
Msg-id | 1028646136.12188.3.camel@taru.tm.ee обсуждение исходный текст |
Ответ на | Re: FUNC_MAX_ARGS benchmarks (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: FUNC_MAX_ARGS benchmarks
|
Список | pgsql-hackers |
On Tue, 2002-08-06 at 15:36, Tom Lane wrote: > "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes: > > I was thinking of looking at turning names to varchars/text in order to test > > the performance hit [in the first instance]. However doing a > > find . -name \*\.\[ch\] | xargs grep NAMEDATALEN | wc -l > > gives 185 hits and some of those are setting other macros. It seems to > > me there is a fair amount of work involved in just getting variable > > length names into the system so that they can be tested. > > And that is not even the tip of the iceberg. The real reason that NAME > is fixed-length is so that it can be accessed as a member of a C > structure. I'm not pretending to know anything about it, but can't this be made into a pointer that is accessed as a member of a C structure. This should not need rearranging the field order. And if we were lucky enough, then change from char[32] to char* will be invisible for most places that use it. > Moving NAME into the variable-length category would make it > much more painful to access than it is now, and would require > rearranging the field order in every system catalog that has a name field. From what I remember the main concern was lack of support for varlen types in cache manager (whatever it means) ? --------------- Hannu
В списке pgsql-hackers по дате отправления: