Re: Using quicksort for every external sort run - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Using quicksort for every external sort run
Date
Msg-id CAM-w4HNSOghz_Z5wsZFTGMy7_9+c_Z73DjrafrVNuHHDiEASvw@mail.gmail.com
Whole thread Raw
In response to Re: Using quicksort for every external sort run  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Using quicksort for every external sort run  (Peter Geoghegan <pg@heroku.com>)
Re: Using quicksort for every external sort run  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Wed, Nov 18, 2015 at 11:29 PM, Peter Geoghegan <pg@heroku.com> wrote:
> Other systems expose this explicitly, and, as I said, say in an
> unqualified way that a multi-pass merge should be avoided. Maybe the
> warning isn't the right way of communicating that message to the DBA
> in detail, but I am confident that it ought to be communicated to the
> DBA fairly clearly.

I'm pretty convinced warnings from DML are a categorically bad idea.
In any OLTP load they're effectively fatal errors since they'll fill
up log files or client output or cause other havoc. Or they'll cause
no problem because nothing is reading them. Neither behaviour is
useful.

Perhaps the right thing to do is report a statistic to pg_stats so
DBAs can see how often sorts are in memory, how often they're on disk,
and how often the on disk sort requires n passes. That would put them
in the same category as "sequential scans" for DBAs that expect the
application to only run index-based OLTP queries for example. The
problem with this is that sorts are not tied to a particular relation
and without something to group on the stat will be pretty hard to act
on.


-- 
greg



pgsql-hackers by date:

Previous
From: Mike Blackwell
Date:
Subject: warning: HS_KEY redefined (9.5 beta2)
Next
From: Robert Haas
Date:
Subject: Re: Getting sorted data from foreign server for merge join