On 6/18/09, Simon Riggs <si...@2ndquadrant.com> wrote: > On Tue, 2009-06-16 at 10:23 -0400, Tom Lane wrote: > > Speaking of which, what about some performance numbers? Like Heikki, > > I'm quite suspicious of whether there is any real-world gain to be had > > from this approach. > > > It has been "lore" for some time that VARCHAR is cheaper than > VARCHAR(n), so I'm looking forward to this improvement as a real-world > gain. (If done right). > > I've looked at the code and the thing that bothers me is that I can't > see where or why bcTruelen would be called more often for VARCHAR(n) > than it would be for VARCHAR, on a Select/Sort only workload.
I'd guess plain VARCHAR simply does not have blanks at the end, so Truelen is cheap. > Are we tuning the right thing? Is there some code we can completely > avoid? > > If not, does this mean it is a generic effect? Does this imply that > NUMERIC(n) is somehow worse than NUMERIC? etc.. Probably not. For numeric the (n) seems to be only checked input time. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
