> On 12 Mar 2020, at 18:51, Tom Lane wrote:
>
> […]
>
> I didn't want to spend any more effort on it than that, because I'm
> not really on board with this line of attack.
Appreciate that. It was about the approach that I was most keen to get feedback
upon.
> This patch seems
> awfully
On Fri, Mar 13, 2020 at 7:51 AM Tom Lane wrote:
> ... (At least on the Linux side. I guess the cfbot's
> Windows builds are sans cassert, which seems like an odd choice.)
I tried turning that on by adding $config{asserts} = 1 in the build
script and adding some scripting to dump all relevant
The cfbot is still not happy with this, because you're ignoring the
project style rule against C99-like mixing of code and declarations.
I went to fix that, and soon found that the code doesn't compile,
much less pass regression tests, with --enable-cassert. That's
really a serious error on your
> On 28 Jan 2020, at 09:56, Thomas Munro wrote:
>
> ([…] I have no
> idea what GUI interaction causes that, but most Apple Mail attachments
> seem to be fine.)
I gathered from the other thread that posting plain text seems to attach the
patches in a way that’s more acceptable. Seems to work,
On Tue, Jan 28, 2020 at 9:59 PM Dent John wrote:
> I’ll look at it. Probably won’t be able to until after the commitfest closes
> though.
(We've seen that hidden attachment problem from Apple Mail before,
discussion of the MIME details in the archives somewhere. I have no
idea what GUI
Thanks Tom.
I’ll look at it. Probably won’t be able to until after the commitfest closes
though.
d.
> On 28 Jan 2020, at 02:58, Tom Lane wrote:
>
> Dent John writes:
>> I’ve updated the patch, addressed the rescan issue, and restructured the
>> tests.
>> [ pipeline-functionscan-v4.patch
Dent John writes:
> I’ve updated the patch, addressed the rescan issue, and restructured the
> tests.
> [ pipeline-functionscan-v4.patch ]
FWIW, this patch doesn't apply to HEAD anymore. The cfbot
has failed to notice because it is still testing the v3 patch.
Apparently the formatting of this
Hi folks,I’ve updated the patch, addressed the rescan issue, and restructured the tests.I’ve taken a slightly different approach this time, re-using the (already pipeline-supporting) machinery of the Materialize node, and extended it to allow an SFRM_Materialize SRF to donate the tuplestore it
>> On 3 Nov 2019, at 13:33, Pavel Stehule wrote:
>>
>> can be nice, if patch has some regress tests - it is good for memory
>> refreshing what is target of patch.
I’ve updated the patch, and added some regression tests.
denty.
pipeline-functionscan-v3.patch
Description: Binary data
> On 3 Nov 2019, at 13:33, Pavel Stehule wrote:
>
> can be nice, if patch has some regress tests - it is good for memory
> refreshing what is target of patch.
With a suitably small work_mem constraint, it is possible to show the absence
of buffers resulting from the tuplestore. It’ll need
Hi
ne 3. 11. 2019 v 12:51 odesílatel Dent John napsal:
> (And here’s aforementioned attachment… doh.)
>
can be nice, if patch has some regress tests - it is good for memory
refreshing what is target of patch.
Regards
Pavel
(And here’s aforementioned attachment… doh.)
pipeline-functionscan-v2.patch
Description: Binary data
Hi,
Turns out — to my embarrassment — that pretty much all of the regression tests
failed with my patch. No idea if anyone spotted that and withheld reply in
revenge, but I wouldn’t blame if you did!
I have spent a bit more time on it. The attached patch is a much better show,
though there
On 22 Sep 2019, at 16:01, Tom Lane wrote:Hi Tom,I don't know of anybody working on it.Okay. I had a look at this. I tried to apply Andre’s patch [1] from some time ago, but that turned out not so easy. I guess the code has moved on since. So I’ve attempted to re-invent the
On Sun, Jul 21, 2019 at 5:55 PM Tom Lane wrote:
> The FROM case could be improved perhaps, if somebody wanted to put
> time into it. You'd still need to be prepared to build a tuplestore,
> in case of rescan or backwards fetch; but in principle you could return
> rows immediately while stashing
Dent John writes:
> On 21 Jul 2019, at 22:54, Tom Lane wrote:
>> Chapman Flack writes:
>>> But looking in the code, I'm getting the impression that those
>>> benefits are only theoretical future ones, as ExecMakeTableFunctionResult
>>> implements SFRM_ValuePerCall mode by ... repeatedly calling
Chapman Flack writes:
> Until now, I had assumed that SFRM_ValuePerCall mode might offer some
> benefits, such as the possibility of pipelining certain queries and not
> building up a whole tuplestore in advance.
> But looking in the code, I'm getting the impression that those
> benefits are
On 06/15/19 21:46, Chapman Flack wrote:
> On 06/15/19 21:21, Tom Lane wrote:
>> Yup. (Of course, you don't have to use the SRF_FIRSTCALL_INIT
>> infrastructure.)
>
> That had crossed my mind ... but it seems there's around 80 or 100
> lines of good stuff there that'd be a shame to duplicate. If
On 06/15/19 21:21, Tom Lane wrote:
> Yup. (Of course, you don't have to use the SRF_FIRSTCALL_INIT
> infrastructure.)
That had crossed my mind ... but it seems there's around 80 or 100
lines of good stuff there that'd be a shame to duplicate. If only
init_MultiFuncCall() took an extra void **
Chapman Flack writes:
> So please let me know if I seem to correctly understand the limits
> on its use.
> I gather that various extensions use it to stash various things. But
> (I assume) ... they will only touch fn_extra in FmgrInfo structs that
> pertain to *their own functions*. (Please say
20 matches
Mail list logo