Re: PassDownLimitBound for ForeignScan/CustomScan [take-2]

From: "Tels" <nospam-pg-abuse(at)bloodgate(dot)com>
To: "Kouhei Kaigai" <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "Jeevan Chalke" <jeevan(dot)chalke(at)enterprisedb(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Etsuro Fujita" <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, "Andres Freund" <andres(at)anarazel(dot)de>, "Kohei KaiGai" <kaigai(at)kaigai(dot)gr(dot)jp>
Subject: Re: PassDownLimitBound for ForeignScan/CustomScan [take-2]
Date: 2017-03-10 08:27:30
Message-ID: 7579d031fdf96d2c91e09967fb96272f.squirrel@sm.webmail.pair.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

On Wed, March 1, 2017 7:21 pm, Kouhei Kaigai wrote:
>> I've looked at the patch, and as I'm not that familiar with the
>> pg-sourcecode,
>> customs and so on, this isn't a review, more like food for thought and
>> all
>> should be taken with a grain of salt. :)
>>
>> So here are a few questions and remarks:
>>
>> >+ double limit_tuples = -1.0;
>>
>> Surely the limit cannot be fractional, and must be an integer. So
>> wouldn't
>> it be better the same type as say:
>>
>> >+ if (root->limit_tuples >= 0.0 &&
>>
>> Than you could also compare with ">= 0", not ">= 0.0".
>>
> The above variable represents the "estimated" number of rows at the
> planning stage, not execution time.
> You may be able to see Path structure has "rows" field declared as
> double type. It makes sense to consider stupid paths during planning,
> even if it is eventually rejected. For example, if a cross join with
> two large tables appear during planning, 64bit integer will make overflow
> easily.

Hm, ok. Not related to your patch, just curious: Is there a mechanism in
place that automatically rejects plans where the limit would overflow the
double to uint64 conversation? Or is this more of a "there would be
hopefully a plan with a better limit so we do not use the bad one"?

Would it possible to force a plan where such overflow would occur?

>> And this comment might be better "were we already called?"
>>
>> >+ bool rs_started; /* are we already
>> called? */
>>
> Other variables in ResultState uses present form, like:
>
> + bool rs_started; /* are we already called? */
> bool rs_done; /* are we done? */
> bool rs_checkqual; /* do we need to check the qual? */
> } ResultState;

Yes, I noted that, but still "are" and "called" and "already" don't read
well together for me:

are - present form
called - past form like "were we called?", or "are we called bob?" an
ongoing process
already - it has started

So "are we already called" reads like someone is waiting for being called.

Maybe to mirror the comment on "rs_done":

/* have we started yet? */

Also, maybe it's easier for the comment to describe what is happening in
the code because of the flag, not just to the flag itself:

/* To do things once when we are called */

Anyway, it is a minor point and don't let me distract you from your work,
I do like the feature and the patch :)

Best wishes,

Tels

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2017-03-10 08:35:39 Re: Parallel Append implementation
Previous Message Jim Nasby 2017-03-10 08:27:00 Re: Need a builtin way to run all tests faster manner