Re: Tuplesort merge pre-reading - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Tuplesort merge pre-reading
Date
Msg-id CA+TgmoZ2EqTiyKmd2MAg-GesYK_A81nRg=V9csEC1ZO1tQMvkQ@mail.gmail.com
Whole thread Raw
In response to Re: Tuplesort merge pre-reading  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Tuplesort merge pre-reading  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On Thu, Sep 29, 2016 at 6:52 AM, Peter Geoghegan <pg@heroku.com> wrote:
>> How is it awkward?
>
> Maybe that was the wrong choice of words. What I mean is that it seems
> somewhat unprincipled to give over an equal share of memory to each
> active-at-least-once tape, ...

I don't get it.  If the memory is being used for prereading, then the
point is just to avoid doing many small I/Os instead of one big I/O,
and that goal will be accomplished whether the memory is equally
distributed or not; indeed, it's likely to be accomplished BETTER if
the memory is equally distributed than if it isn't.

I can imagine that there might be a situation in which it makes sense
to give a bigger tape more resources than a smaller one; for example,
if one were going to divide N tapes across K worker processess and
make individual workers or groups of workers responsible for sorting
particular tapes, one would of course want to divide up the data
across the available processes relatively evenly, rather than having
some workers responsible for only a small amount of data and others
for a very large amount of data.  But such considerations are
irrelevant here.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Set log_line_prefix and application name in test drivers
Next
From: Tom Lane
Date:
Subject: Re: Set log_line_prefix and application name in test drivers