At Thu, 28 Feb 2019 13:32:17 +0300, Surafel Temesgen <surafel3...@gmail.com>
wrote in <calay4q_trfn2z1oqcpxckb5diy+a7m5hhg4vov5d1bawpf+...@mail.gmail.com>
> On Sun, Feb 24, 2019 at 12:27 AM Tomas Vondra <tomas.von...@2ndquadrant.com>
> wrote:
>
> >
> > I'm sorry, I still don't understand what the supposed problem is. I
> > don't think it's all that different from what nodeMaterial.c does, for
> > example.
> >
> >
> sorry for the noise .Attache is complete patch for incremental approach
Mmm. It seems just moving
reading-all-before-return-the-first-tuple from LIMIT_INITIAL to
LIMIT_RESCAN. If I read it correctly node->conut is not correct
since it is calculated as "the percentage of the number of tuples
read *so far* excluding the offset portion.).
| while (node->position - node->offset >= node->count)
| {
| slot = ExecProcNode(outerPlan);
| (if Tupleis Null then break;)
| tuplestore_puttupleslot(node->tuple_store, slot);
| cnt = tuplestore_tuple_count(node->tuple_store);
| node->count = ceil(node->percent * cnt / 100.0);
| }
If I'm missing nothing, this seems almost same with the follows.
while ((position - offset) * percent / 100 >=
(position - offset) * percent / 100) {}
In the first place, the patch breaks nodeLimit.c and build fails.
====
- * previous time we got a different result.
+ * previous time we got a different result.In PERCENTAGE option there
are
+ * no bound on the number of output tuples */
*/
====
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
