(2019/03/29 22:18), Etsuro Fujita wrote:
Attached is a
new version. If there are no objections, I'll commit this version.
Pushed after polishing the patchset a bit further: add an assertion,
tweak comments, and do cleanups. Thanks for reviewing, Antonin and Jeff!
Best regards,
Etsuro Fujita
(2019/03/20 20:47), Etsuro Fujita wrote:
Attached is an updated version of the patch set.
One thing I noticed while self-reviewing the patch for UPPERREL_FINAL
is: the previous versions of the patch don't show EPQ plans in EXPLAIN,
as shown in the below example, so we can't check if those pla
(2019/03/09 1:25), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/03/01 20:16), Antonin Houska wrote:
Etsuro Fujita wrote:
Conversely, it appears that add_foreign_ordered_paths() added by the patchset
would generate such pre-sorted paths *redundantly* when the input_rel is the
final sca
Etsuro Fujita wrote:
> (2019/03/01 20:16), Antonin Houska wrote:
> > Etsuro Fujita wrote:
>
> >> Conversely, it appears that add_foreign_ordered_paths() added by the
> >> patchset
> >> would generate such pre-sorted paths *redundantly* when the input_rel is
> >> the
> >> final scan/join relat
(2019/02/22 17:17), Etsuro Fujita wrote:
(2019/02/21 6:19), Jeff Janes wrote:
With your tweaks, I'm still not seeing the ORDER-less LIMIT get pushed
down when using use_remote_estimate in a simple test case, either with
this set of patches, nor in the V4 set. However, without
use_remote_estima
(2019/03/01 20:16), Antonin Houska wrote:
Etsuro Fujita wrote:
Conversely, it appears that add_foreign_ordered_paths() added by the patchset
would generate such pre-sorted paths *redundantly* when the input_rel is the
final scan/join relation. Will look into that.
Currently I have no idea
(2019/03/04 16:46), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/03/01 20:00), Antonin Houska wrote:
It's still unclear to me why add_foreign_ordered_paths() passes the input
relation (input_rel) to estimate_path_cost_size(). If it passed the output rel
(i.e. ordered_rel in this case) li
(2019/03/02 1:14), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/03/01 20:00), Antonin Houska wrote:
Sorry, my explanation was not enough again, but I showed that query ("SELECT
a+b, random() FROM foreign_table GROUP BY a+b ORDER BY a+b;") to explain why
the following code bit is needed:
Etsuro Fujita wrote:
> (2019/03/01 20:00), Antonin Houska wrote:
> > Etsuro Fujita wrote:
> > It's still unclear to me why add_foreign_ordered_paths() passes the input
> > relation (input_rel) to estimate_path_cost_size(). If it passed the output
> > rel
> > (i.e. ordered_rel in this case) lik
Etsuro Fujita wrote:
> (2019/03/01 20:00), Antonin Houska wrote:
> > Etsuro Fujita wrote:
> > I used gdb to help me understand, however the condition
> >
> > if (fpextra&& !IS_UPPER_REL(foreignrel))
> >
> > never evaluated to true with the query above.
>
> Sorry, my explanation was not en
(2019/03/01 20:00), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/02/22 22:54), Antonin Houska wrote:
Etsuro Fujita wrote:
So, the two changes are handling different
cases, hence both changes would be required.
+ /*
+* If this is an UPPERREL_ORDERED step performed on the
Etsuro Fujita wrote:
> (2019/02/23 0:21), Antonin Houska wrote:
> > Etsuro Fujita wrote:
>
> >>> (2019/02/08 2:04), Antonin Houska wrote:
> * regression tests: I think test(s) should be added for queries that have
> ORDER BY clause but do not have GROUP BY (and also no LIMIT / OFFSET)
Etsuro Fujita wrote:
> (2019/02/22 22:54), Antonin Houska wrote:
> > Etsuro Fujita wrote:
> >> On the other hand, the code bit added by
> >> 0001-postgres_fdw-Perform-UPPERREL_ORDERED-step-remotely-v3.patch handles
> >> the
> >> case where a post-scan/join processing step other than grouping/ag
(2019/02/22 22:54), Antonin Houska wrote:
Etsuro Fujita wrote:
Maybe, my explanation in that thread was not enough, but the changes proposed
by the patch posted there wouldn't obsolete the above. Let me explain using a
foreign-table variant of the example shown in the comments for
make_group_i
(2019/02/23 0:21), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/02/08 2:04), Antonin Houska wrote:
* regression tests: I think test(s) should be added for queries that have
ORDER BY clause but do not have GROUP BY (and also no LIMIT / OFFSET)
clause. I haven't noticed such tests.
I no
Etsuro Fujita wrote:
> (2019/02/08 21:35), Etsuro Fujita wrote:
> > (2019/02/08 2:04), Antonin Houska wrote:
> >> * regression tests: I think test(s) should be added for queries that have
> >> ORDER BY clause but do not have GROUP BY (and also no LIMIT / OFFSET)
> >> clause. I haven't noticed s
Etsuro Fujita wrote:
> Maybe, my explanation in that thread was not enough, but the changes proposed
> by the patch posted there wouldn't obsolete the above. Let me explain using a
> foreign-table variant of the example shown in the comments for
> make_group_input_target():
>
> SELECT a+b,
Hi Jeff,
(2019/02/21 6:19), Jeff Janes wrote:
On Wed, Jan 30, 2019 at 6:12 AM Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2018/12/28 15:50), Etsuro Fujita wrote:
> Attached is a new version of the
> patch.
Here is an updated version of the patch set. Changes a
On Wed, Jan 30, 2019 at 6:12 AM Etsuro Fujita
wrote:
> (2018/12/28 15:50), Etsuro Fujita wrote:
> > Attached is a new version of the
> > patch.
>
> Here is an updated version of the patch set. Changes are:
>
> * In the previous version, LIMIT without OFFSET was not performed
> remotely as the co
(2019/02/18 23:21), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/02/15 21:46), Antonin Houska wrote:
ok, I understand now. I assume that the patch
https://www.postgresql.org/message-id/5C66A056.60007%40lab.ntt.co.jp
obsoletes the code snippet we discussed above.
Sorry, I don't understa
Etsuro Fujita wrote:
> (2019/02/15 21:46), Antonin Houska wrote:
> > ok, I understand now. I assume that the patch
> >
> > https://www.postgresql.org/message-id/5C66A056.60007%40lab.ntt.co.jp
> >
> > obsoletes the code snippet we discussed above.
>
> Sorry, I don't understand this. Could you el
(2019/02/15 21:46), Antonin Houska wrote:
ok, I understand now. I assume that the patch
https://www.postgresql.org/message-id/5C66A056.60007%40lab.ntt.co.jp
obsoletes the code snippet we discussed above.
Sorry, I don't understand this. Could you elaborate on that?
Best regards,
Etsuro Fujit
(2019/02/15 21:19), Etsuro Fujita wrote:
So, here is an updated patch. If there are no objections from you or
anyone else, I'll commit the patch as a preliminary one for what's
proposed in this thread.
Pushed, after fiddling with the commit message a bit.
Best regards,
Etsuro Fujita
Etsuro Fujita wrote:
> (2019/02/12 18:03), Antonin Houska wrote:
> > Etsuro Fujita wrote:
> >> (2019/02/08 2:04), Antonin Houska wrote:
> >>>
> >>> And maybe related problem: why should FDW care about the effect of
> >>> apply_scanjoin_target_to_paths() like you claim to do here?
> >>>
> >>> /
(2019/02/14 18:44), Etsuro Fujita wrote:
(2019/02/12 20:43), Antonin Houska wrote:
Etsuro Fujita wrote:
Here are my review comments:
root->upper_targets[UPPERREL_FINAL] = final_target;
+ root->upper_targets[UPPERREL_ORDERED] = final_target;
root->upper_targets[UPPERREL_WINDOW] = sort_input_tar
(2019/02/12 18:03), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/02/08 2:04), Antonin Houska wrote:
Some comments on coding:
0001-postgres_fdw-Perform-UPPERREL_ORDERED-step-remotely-v3.patch
-
* I'm not sure if UPPERREL_ORDE
(2019/02/12 20:43), Antonin Houska wrote:
Etsuro Fujita wrote:
Here are my review comments:
root->upper_targets[UPPERREL_FINAL] = final_target;
+ root->upper_targets[UPPERREL_ORDERED] = final_target;
root->upper_targets[UPPERREL_WINDOW] = sort_inpu
Etsuro Fujita wrote:
> (2019/02/08 21:35), Etsuro Fujita wrote:
> > (2019/02/08 2:04), Antonin Houska wrote:
> >> * add_foreign_ordered_paths()
> >>
> >> Exprssion root->upper_targets[UPPERREL_FINAL] is used to access the
> >> target.
> >>
> >> I think create_ordered_paths() should actually set t
Etsuro Fujita wrote:
> (2019/02/08 2:04), Antonin Houska wrote:
>
> > First, I wonder if the information on LIMIT needs to be passed to the
> > FDW. Cannot the FDW routines use root->tuple_fraction?
>
> I think it's OK for the FDW to use the tuple_fraction, but I'm not sure the
> tuple_fraction
(2019/02/08 21:35), Etsuro Fujita wrote:
(2019/02/08 2:04), Antonin Houska wrote:
* add_foreign_ordered_paths()
Exprssion root->upper_targets[UPPERREL_FINAL] is used to access the
target.
I think create_ordered_paths() should actually set the target so that
postgresGetForeignUpperPaths() can s
Hi Antonin,
(2019/02/08 2:04), Antonin Houska wrote:
Etsuro Fujita wrote:
Here is an updated version of the patch set. Changes are:
I've spent some time reviewing the patches.
Thanks for the review!
First, I wonder if the information on LIMIT needs to be passed to the
FDW. Cannot the FD
Etsuro Fujita wrote:
> (2018/12/28 15:50), Etsuro Fujita wrote:
> > Attached is a new version of the
> > patch.
>
> Here is an updated version of the patch set. Changes are:
I've spent some time reviewing the patches.
First, I wonder if the information on LIMIT needs to be passed to the
FDW.
(2018/12/26 16:35), Etsuro Fujita wrote:
Attached is an updated version of the patch. Other changes:
While self-reviewing the patch I noticed a thinko in the patch 0001 for
pushing down the final sort: I estimated the costs for that using
estimate_path_cost_size that was modified so that it f
(2018/12/17 22:09), Etsuro Fujita wrote:
Here is a set of WIP patches for pushing down ORDER BY LIMIT to the remote:
For some regression test cases with ORDER BY and/or LIMIT, I noticed
that these patches still cannot push down those clause to the remote. I
guess it would be needed to tweak th
(2018/12/17 22:09), Etsuro Fujita wrote:
Here is a set of WIP patches for pushing down ORDER BY LIMIT to the remote:
* 0001-postgres-fdw-upperrel-ordered-WIP.patch:
Correction:
0001-postgres_fdw-Perform-UPPERREL_ORDERED-step-remotely-WIP.patch
* 0002-postgres-fdw-upperrel-final-WIP.patch:
(2018/10/09 14:48), Etsuro Fujita wrote:
(2018/10/05 19:15), Etsuro Fujita wrote:
(2018/08/02 23:41), Tom Lane wrote:
Andrew Gierth writes:
[ postgres_fdw is not smart about exploiting fast-start plans ]
Yeah, that's basically not accounted for at all in the current design.
One possibility
(2018/10/05 19:15), Etsuro Fujita wrote:
(2018/08/02 23:41), Tom Lane wrote:
Andrew Gierth writes:
[ postgres_fdw is not smart about exploiting fast-start plans ]
Yeah, that's basically not accounted for at all in the current design.
One possibility: would it be worth adding an option to EX
(2018/08/02 23:41), Tom Lane wrote:
Andrew Gierth writes:
[ postgres_fdw is not smart about exploiting fast-start plans ]
Yeah, that's basically not accounted for at all in the current design.
One possibility: would it be worth adding an option to EXPLAIN that
makes it assume cursor_tuple_f
Andrew Gierth writes:
> [ postgres_fdw is not smart about exploiting fast-start plans ]
Yeah, that's basically not accounted for at all in the current design.
> One possibility: would it be worth adding an option to EXPLAIN that
> makes it assume cursor_tuple_fraction?
[ handwaving ahead ]
I w
Hello.
At Thu, 02 Aug 2018 01:06:41 +0100, Andrew Gierth
wrote in <87pnz1aby9@news-spur.riddles.org.uk>
> This analysis comes from investigating a report from an IRC user. A
> summary of the initial report is:
>
> Using PG 9.6.9 and postgres_fdw, a query of the form "select * from
> for
This analysis comes from investigating a report from an IRC user. A
summary of the initial report is:
Using PG 9.6.9 and postgres_fdw, a query of the form "select * from
foreign_table order by col limit 1" is getting a local Sort plan, not
pushing the ORDER BY to the remote. Turning off use_
41 matches
Mail list logo
