| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeremy Kerr <jk(at)ozlabs(dot)org>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> |
| Subject: | Re: [PATCH] backend: compare word-at-a-time in bcTruelen |
| Date: | 2009-06-18 11:12:55 |
| Message-ID: | 1245323575.3895.194.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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..
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marko Kreen | 2009-06-18 12:14:41 | Re: [PATCH] backend: compare word-at-a-time in bcTruelen |
| Previous Message | Heikki Linnakangas | 2009-06-18 10:11:31 | Re: typos in source comment |