| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Greg Stark <stark(at)mit(dot)edu>, Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thom Brown <thom(at)linux(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: B-Tree support function number 3 (strxfrm() optimization) |
| Date: | 2014-04-08 21:48:52 |
| Message-ID: | 20140408214851.GO5822@eldon.alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Geoghegan wrote:
> What I have here looks like it speeds things up a little over 200% (so
> a little over 300% of the original throughput) with a single client
> for many representative cases. That's a massive difference, to the
> point that I don't see a lot of sense in considering fmgr-elision
> alone separately.
I think the point here is what matters is that that gain from the
strxfrm part of the patch is large, regardless of what the baseline is
(right?). If there's a small loss in an uncommon worst case, that's
probably acceptable, as long as the worst case is uncommon and the loss
is small. But if the loss is large, or the case is not uncommon, then a
fix for the regression is going to be a necessity.
You seem to be assuming that a fix for whatever regression is found is
going to be impossible to find.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-04-08 21:48:55 | Re: Default gin operator class of jsonb failing with index row size maximum reached |
| Previous Message | Tom Lane | 2014-04-08 21:46:22 | default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) |