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
https://commitfest.pos
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
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 r
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 "
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 parameter
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 about
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:
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 the
>
> 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 mat
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 t
> 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 the
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 ma
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);
> > +
> > + svf->
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 != SVFO
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;
+
+ deparseSQLValueFuncti
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) &&
> >>
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
treat
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 ab
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 no
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 PostgreS
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.
>
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 w
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.
>
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"
Col
24 matches
Mail list logo
