Re: Push down time-related SQLValue functions to foreign server

2022-08-02 Thread Jacob Champion
This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting

Re: Push down time-related SQLValue functions to foreign server

2022-01-21 Thread Tom Lane
Alexander Pyhalov writes: > So far I have the following prototype. It seems to be working, but I > think it can be enhanced. > At least, some sort of caching seems to be necessary for > is_stable_expr(). Yeah, from a performance standpoint this seems pretty horrid --- it's probably exponential

Re: Push down time-related SQLValue functions to foreign server

2022-01-20 Thread Alexander Pyhalov
Tom Lane писал 2022-01-18 23:01: I wrote: Alexander Pyhalov writes: This means we'll translate something like explain select * from t where d > now() - '1 day'::interval; to select * from t where d > $1; Right. After thinking about that a bit more, I see that this will result in a major

Re: Push down time-related SQLValue functions to foreign server

2022-01-18 Thread Tom Lane
I wrote: > Alexander Pyhalov writes: >> This means we'll translate something like >> explain select * from t where d > now() - '1 day'::interval; >> to >> select * from t where d > $1; > Right. After thinking about that a bit more, I see that this will result in a major redefinition of what is

Re: Push down time-related SQLValue functions to foreign server

2022-01-18 Thread Tom Lane
Alexander Pyhalov writes: > Tom Lane писал 2022-01-18 19:53: >> However, before we proceed any further with this patch, I think we >> really ought to stop and think about the question I raised last >> night: why are we building a one-off feature for SQLValueFunction? >> Wouldn't the same

Re: Push down time-related SQLValue functions to foreign server

2022-01-18 Thread Alexander Pyhalov
Tom Lane писал 2022-01-18 19:53: Alexander Pyhalov writes: [ updated patch ] Thanks for updating the patch. (BTW, please attach version numbers to new patch versions, to avoid confusion.) However, before we proceed any further with this patch, I think we really ought to stop and think

Re: Push down time-related SQLValue functions to foreign server

2022-01-18 Thread Tom Lane
Alexander Pyhalov writes: > [ updated patch ] Thanks for updating the patch. (BTW, please attach version numbers to new patch versions, to avoid confusion.) However, before we proceed any further with this patch, I think we really ought to stop and think about the question I raised last night:

Re: Push down time-related SQLValue functions to foreign server

2022-01-18 Thread Alexander Pyhalov
Hi. Tom Lane писал 2022-01-18 02:08: Alexander Pyhalov writes: Perhaps in a MACRO? Changed this check to a macro, also fixed condition in is_foreign_param() and added test for it. Also fixed comment in prepare_query_params(). I took a quick look at this. I'm unconvinced that you need

Re: Push down time-related SQLValue functions to foreign server

2022-01-17 Thread Corey Huinker
> > Hmm ... not really, because for these particular functions, the > point is exactly that we *don't* translate them to some function > call on the remote end. We evaluate them locally and push the > resulting constant to the far side, thus avoiding issues like > clock skew. > Ah, my pattern

Re: Push down time-related SQLValue functions to foreign server

2022-01-17 Thread Tom Lane
Corey Huinker writes: > I'm very late to the party, but it seems to me that this effort is > describing a small subset of what "routine mapping" seems to be for: > defining function calls that can be pushed down to the foreign server, and > the analogous function on the foreign side. We may want

Re: Push down time-related SQLValue functions to foreign server

2022-01-17 Thread Corey Huinker
> The implementation of converting now() to CURRENT_TIMESTAMP > seems like an underdocumented kluge, too. > I'm very late to the party, but it seems to me that this effort is describing a small subset of what "routine mapping" seems to be for: defining function calls that can be pushed down to

Re: Push down time-related SQLValue functions to foreign server

2022-01-17 Thread Tom Lane
Alexander Pyhalov writes: >> Perhaps in a MACRO? > Changed this check to a macro, also fixed condition in > is_foreign_param() and added test for it. > Also fixed comment in prepare_query_params(). I took a quick look at this. I'm unconvinced that you need the TIME_RELATED_SQLVALUE_FUNCTION

Re: Push down time-related SQLValue functions to foreign server

2021-08-20 Thread Ranier Vilela
Em sex., 20 de ago. de 2021 às 09:18, Alexander Pyhalov < a.pyha...@postgrespro.ru> escreveu: > Ranier Vilela писал 2021-08-20 14:19: > > > Another question: > > For 0002 patch: > > > > + if (node->funcid == F_NOW) > > + { > > + SQLValueFunction *svf = makeNode(SQLValueFunction); > > + > > +

Re: Push down time-related SQLValue functions to foreign server

2021-08-20 Thread Zhihong Yu
On Fri, Aug 20, 2021 at 12:13 AM Alexander Pyhalov wrote: > Hi. > > Ranier Vilela писал 2021-08-19 14:01: > > Em qui., 19 de ago. de 2021 às 07:50, Zhihong Yu > >> Hi, > >> For 0001 patch: > >> > >> + if ((s->op != SVFOP_CURRENT_TIMESTAMP) && > >> + (s->op !=

Re: Push down time-related SQLValue functions to foreign server

2021-08-20 Thread Alexander Pyhalov
Ranier Vilela писал 2021-08-20 14:19: Another question: For 0002 patch: + if (node->funcid == F_NOW) + { + SQLValueFunction *svf = makeNode(SQLValueFunction); + + svf->op = SVFOP_CURRENT_TIMESTAMP; + svf->type = TIMESTAMPTZOID; + svf->typmod = -1; + svf->location = -1; + +

Re: Push down time-related SQLValue functions to foreign server

2021-08-20 Thread Ranier Vilela
Em sex., 20 de ago. de 2021 às 04:13, Alexander Pyhalov < a.pyha...@postgrespro.ru> escreveu: > Hi. > > Ranier Vilela писал 2021-08-19 14:01: > > Em qui., 19 de ago. de 2021 às 07:50, Zhihong Yu > >> Hi, > >> For 0001 patch: > >> > >> + if ((s->op != SVFOP_CURRENT_TIMESTAMP) && >

Re: Push down time-related SQLValue functions to foreign server

2021-08-20 Thread Alexander Pyhalov
Hi. Ashutosh Bapat писал 2021-08-19 17:01: I spent some time looking at this patch. Generally it looks like a good idea. These stable functions will be evaluated at the execution time and replaced with constants. I am not sure whether the nodes saved in the param_list may not get the same

Re: Push down time-related SQLValue functions to foreign server

2021-08-20 Thread Alexander Pyhalov
Hi. Ranier Vilela писал 2021-08-19 14:01: Em qui., 19 de ago. de 2021 às 07:50, Zhihong Yu Hi, For 0001 patch: + if ((s->op != SVFOP_CURRENT_TIMESTAMP) && + (s->op != SVFOP_CURRENT_TIMESTAMP_N) && + (s->op != SVFOP_CURRENT_TIME) && ... The

Re: Push down time-related SQLValue functions to foreign server

2021-08-19 Thread Ashutosh Bapat
I spent some time looking at this patch. Generally it looks like a good idea. These stable functions will be evaluated at the execution time and replaced with constants. I am not sure whether the nodes saved in the param_list may not get the same treatment. Have you verified that? Also the new

Re: Push down time-related SQLValue functions to foreign server

2021-08-19 Thread Ranier Vilela
Em qui., 19 de ago. de 2021 às 07:50, Zhihong Yu escreveu: > > > On Thu, Aug 19, 2021 at 2:52 AM Alexander Pyhalov < > a.pyha...@postgrespro.ru> wrote: > >> Hi. >> >> The attached patches allow pushing down >> current_timestamp/localtimestamp/current_time/localtime and now() to >> remote

Re: Push down time-related SQLValue functions to foreign server

2021-08-19 Thread Zhihong Yu
On Thu, Aug 19, 2021 at 2:52 AM Alexander Pyhalov wrote: > Hi. > > The attached patches allow pushing down > current_timestamp/localtimestamp/current_time/localtime and now() to > remote PostgreSQL server as locally computed parameters. > The idea is based on oracle_fdw behavior. > > Examples. >

Re: Push down time-related SQLValue functions to foreign server

2021-08-19 Thread Alexander Pyhalov
Zhihong Yu писал 2021-08-19 13:22: Hi, For 0002 patch: + /* now() is stable, but we can ship it as it's replaced by parameter */ + return !(func_volatile(func_id) == PROVOLATILE_IMMUTABLE || func_id == F_NOW); Did you mean to say 'now() is unstable' ? No, it's stable, not immutable, so

Re: Push down time-related SQLValue functions to foreign server

2021-08-19 Thread Zhihong Yu
On Thu, Aug 19, 2021 at 2:52 AM Alexander Pyhalov wrote: > Hi. > > The attached patches allow pushing down > current_timestamp/localtimestamp/current_time/localtime and now() to > remote PostgreSQL server as locally computed parameters. > The idea is based on oracle_fdw behavior. > > Examples. >

Push down time-related SQLValue functions to foreign server

2021-08-19 Thread Alexander Pyhalov
Hi. The attached patches allow pushing down current_timestamp/localtimestamp/current_time/localtime and now() to remote PostgreSQL server as locally computed parameters. The idea is based on oracle_fdw behavior. Examples. \d test Foreign table "public.test"