Re: Tuplesort merge pre-reading

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Claudio Freire <klaussfreire(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Tuplesort merge pre-reading
Date: 2016-09-15 21:26:01
Message-ID: CAM3SWZTqrhturTgS2YczuNgfntwEXGZJ3HUDvZsv2U2T8B2RUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 15, 2016 at 1:51 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> BTW, does a 1-way merge make any sense? I was surprised to see this in the
> log, even without this patch:
>
> LOG: finished 1-way merge step: CPU 0.62s/7.22u sec elapsed 8.43 sec
> STATEMENT: SELECT COUNT(*) FROM (SELECT * FROM medium.random_ints ORDER BY
> i) t;
> LOG: finished 1-way merge step: CPU 0.62s/7.22u sec elapsed 8.43 sec
> STATEMENT: SELECT COUNT(*) FROM (SELECT * FROM medium.random_ints ORDER BY
> i) t;
> LOG: finished 1-way merge step: CPU 0.62s/7.22u sec elapsed 8.43 sec
> STATEMENT: SELECT COUNT(*) FROM (SELECT * FROM medium.random_ints ORDER BY
> i) t;
> LOG: finished 1-way merge step: CPU 0.62s/7.22u sec elapsed 8.43 sec
> STATEMENT: SELECT COUNT(*) FROM (SELECT * FROM medium.random_ints ORDER BY
> i) t;
> LOG: finished 3-way merge step: CPU 0.62s/7.23u sec elapsed 8.44 sec
> STATEMENT: SELECT COUNT(*) FROM (SELECT * FROM medium.random_ints ORDER BY
> i) t;
> LOG: finished 6-way merge step: CPU 0.62s/7.24u sec elapsed 8.44 sec
> STATEMENT: SELECT COUNT(*) FROM (SELECT * FROM medium.random_ints ORDER BY
> i) t;
> LOG: finished 6-way merge step: CPU 0.62s/7.24u sec elapsed 8.45 sec
> STATEMENT: SELECT COUNT(*) FROM (SELECT * FROM medium.random_ints ORDER BY
> i) t;

Another thing that I think it worth pointing out here is that the
number of merge passes shown is excessive, practically speaking. I
suggested that we have something like checkpoint_warning for this last
year, which Greg Stark eventually got behind, but Robert Haas didn't
seem to like. Maybe this idea should be revisited. What do you think?

There is no neat explanation for why it's considered excessive to
checkpoint every 10 seconds, but not every 2 minutes. But, we warn
about the former case by default, and not the latter. It's hard to
know exactly where to draw the line, but that isn't a great reason to
not do it (maybe one extra merge pass is a good threshold -- that's
what I suggested once). I think that other database systems similarly
surface multiple merge passes. It's just inefficient to ever do
multiple merge passes, even if you're very frugal with memory.
Certainly, it's almost impossible to defend doing 3+ passes these
days.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2016-09-15 21:34:06 Re: OpenSSL 1.1 breaks configure and more
Previous Message Tom Lane 2016-09-15 21:22:38 Re: shm_mq_set_sender() crash