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

From: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Tels <nospam-pg-abuse(at)bloodgate(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-02 00:21:44
Message-ID: 9A28C8860F777E439AA12E8AEA7694F8012B9A32@BPXM15GP.gisp.nec.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Hello all,
>
> as this is my first mail to pgsql-hackers, please be gentle :)
>
Welcome to pgsql-hackers,

> 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.

> node->ss.ps.ps_numTuples is f.i. an uint64.
>
> Or is there a specific reason the limit must be a double?
>
The above variable represents "actual" number of rows at the execution
stage. Likely, hardware replacement cycle will come before int64 overflow.

> And finally:
>
> >+ if (node->ss.ps.ps_numTuples > 0)
>
> >+ appendStringInfo(&buf, " LIMIT %ld",
> node->ss.ps.ps_numTuples);
>
> vs.
>
> >+ appendStringInfo(&buf, "%s LIMIT %lu",
> >+ sql,
> node->ss.ps.ps_numTuples);
>
> It seems odd to have two different format strings here for the same variable.
>
Ah, yes, %lu is right because ps_numTuples is uint64.

> A few comments miss "." at the end, like these:
>
> >+ * Also, pass down the required number of tuples
>
> >+ * Pass down the number of required tuples by the upper node
>
OK,

> 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;

Thanks,
----
PG-Strom Project / NEC OSS Promotion Center
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

Attachment Content-Type Size
passdown-limit-fdw.v5.patch application/octet-stream 17.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2017-03-02 00:39:57 Re: Restricting maximum keep segments by repslots
Previous Message Lukas Fittl 2017-03-02 00:12:48 Re: [PATCH] Use $ parameters as replacement characters for pg_stat_statements