Re: B-Tree support function number 3 (strxfrm() optimization)

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Greg Stark <stark(at)mit(dot)edu>, 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-08-07 00:25:45
Message-ID: CAM3SWZSqtA57r1M8NWq3h02Fx5MTNdF1RFATcFdwzcMto+7xbA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 5, 2014 at 8:55 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> However, with work_mem set low enough to get an external sort, the
>> difference is more interesting. If I set work_mem to 10 MB, then the
>> query takes about 10.7 seconds to execute with a suitably patched
>> Postgres. Whereas on master, it consistently takes a full 69 seconds.
>> That's the largest improvement I've seen so far, for any case.
>
> Comparator cost affects external sorts more than it affects internal sorts.
> When I profiled internal and external int4 sorting, btint4cmp() was 0.37% of
> the internal sort profile and 10.26% of the external sort profile.

I took another look at this.

If I run "dd if=/dev/zero of=/home/pg/test", I can see with iotop that
that has about 45 M/s "total disk write" fairly sustainably, with
occasional mild blips during write-back. This is a Crucial mobile SSD,
with an ext4/lvm file system, and happens to be what is close at hand.

If I run the same external sorting query with a patched Postgres, I
see 24 M/s total disk write throughout. With master, it's about 6 M/s,
and falls to 0 during the final 36-way merge. I'm not sure if the same
thing occurs with patched during the final merge, because the
available resolution isn't good enough to be able to tell. Anyway,
it's pretty clear that when patched, the external sort on text is, if
not totally I/O bound, much closer to being I/O bound. A good external
sort algorithm should be at least close to totally I/O bound. This
makes I/O parallelism a viable strategy for speeding up sorts, where
it might not otherwise be. I've heard of people using a dedicated temp
tablespace disk with Postgres to speed up sorting, but that always
seemed to be about reducing the impact on the heap filesystem, or vice
versa. I've never heard of anyone using multiple disks to speed up
sorting with Postgres (which I don't presume means it hasn't been done
at least somewhat effectively). However, with external sort benchmarks
(like http://sortbenchmark.org), using I/O parallelism strategically
seems to be table stakes for external sort entrants.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2014-08-07 01:15:50 Reporting the commit LSN at commit time
Previous Message Jeff Janes 2014-08-06 23:20:01 Re: Fixed redundant i18n strings in json