From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru> |
Cc: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Push down time-related SQLValue functions to foreign server |
Date: | 2022-01-21 19:57:12 |
Message-ID: | 1208694.1642795032@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru> 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 in the size of the expressions considered
because of the repeated recursions.
The approach I had in mind was to extend the responsibility of
foreign_expr_walker to make it deduce the classification of
an expression in a bottom-up fashion. Also, as I noted before,
we don't want to re-deduce that in a later deparse pass, so
maybe we should just go ahead and deparse during foreign_expr_walker.
Not sure about that part. It sounds expensive; but recording the
classification results in a way we could re-use later doesn't seem
too cheap either.
BTW, the patch is just about unreadable as-is. It would have been
better to not have re-indented the bulk of foreign_expr_walker,
leaving that for some later pgindent pass. But that may be moot,
because I don't think we can tolerate the double-recursion approach
you took here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-01-21 20:00:57 | pg_basebackup fsyncs some files despite --no-sync (was: Adding CI to our tree) |
Previous Message | Andres Freund | 2022-01-21 19:49:56 | Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work |