Simon Riggs wrote:
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.
the testcase discusses here is indeed CHAR(n) vs. VARCHAR. To reiterate
- my numbers(8core/16 thread Nehalem xeon with 16 processes) are
46000qps for CHAR(n), 52000 qps for CHAR(n) with Jeremys patch(thout
bcTrueLen is still on top in the profile) and 67000 qps for VARCHAR.
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
