On Thu, 2009-06-18 at 15:14 +0300, Marko Kreen wrote:
> On 6/18/09, Simon Riggs <simon@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.comPostgreSQL Training, Services and Support