On Thu, 2009-06-18 at 15:14 +0300, Marko Kreen wrote: > 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.
If we were comparing CHAR(n) with VARCHAR then I could agree. But we are comparing VARCHAR(n) and VARCHAR. There is no blank padding with VARCHAR, and the two have identical on-disk representations so the cost of bcTruelen looks like it should be identical in each case. Is bcTruelen being called too many times, or is there, as Marko suggests, an explanation as to why calling bcTruelen costs more when we have a typmod set? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
