From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tatsuro Yamada <yamada(dot)tatsuro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] CLUSTER command progress monitor |
Date: | 2017-11-21 21:07:45 |
Message-ID: | CAH2-WzknWhguFqC17Ax512C2UwoHqAE14bsrE+S-Za9u8pDAyQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 2, 2017 at 6:04 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Progress reporting on sorts seems like a tricky problem to me, as I
> said before. In most cases, a sort is going to involve an initial
> stage where it reads all the input tuples and writes out quicksorted
> runs, and then a merge phase where it merges all the output tapes into
> a sorted result. There are some complexities; for example, if the
> number of tapes is really large, then we might need multiple merge
> phases, only the last of which will produce tuples.
This would ordinarily be the point at which I'd say "but you're very
unlikely to require multiple passes for an external sort these days".
But I won't say that on this thread, because CLUSTER generally has
unusually wide tuples, and so is much more likely to be I/O bound, to
require multiple passes, etc. (I bet the v10 enhancements
disproportionately improved CLUSTER performance.)
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Rosenstein | 2017-11-21 21:13:16 | Re: Logical Replication and triggers |
Previous Message | Masahiko Sawada | 2017-11-21 21:06:29 | Re: [HACKERS] Replication status in logical replication |