Re: Parallel tuplesort (for parallel B-Tree index creation)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Subject: Re: Parallel tuplesort (for parallel B-Tree index creation)
Date: 2017-01-31 15:02:37
Message-ID: CA+TgmoY3CruZAB0WZd+K+G2peno=v=-aPxg6yzo0C=1nw116pQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 31, 2017 at 12:15 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>> Should this 64KB minimum be mentioned in the documentation?
>
> You mean user-visible documentation, and not just tuplesort.h? I don't
> think that that's necessary. That's a ludicrously low amount of memory
> for a worker to be limited to anyway. It will never come up with
> remotely sensible use of the feature.

I agree.

>> + if (!btspool->isunique)
>> + {
>> + shm_toc_estimate_keys(&pcxt->estimator, 2);
>> + }
>>
>> Project style: people always tell me to drop the curlies in cases like
>> that. There are a few more examples in the patch.
>
> I only do this when there is an "else" that must have curly braces,
> too. There are plenty of examples of this from existing code, so I
> think it's fine.

But I disagree on this one. I think

if (blah)
stuff();
else
{
thing();
gargle();
}

...is much better than

if (blah)
{
stuff();
}
else
{
thing();
gargle();
}

But if there were a comment on a separate line before the call to
stuff(), then I would do it the second way.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-01-31 15:03:36 Re: An issue in remote query optimization
Previous Message Robert Haas 2017-01-31 14:59:35 Re: Refactoring of replication commands using printsimple