tion I will be happy, but I need some help.
>
> Massimo
>
> Il giorno dom 7 feb 2021 alle ore 22:35 Dent John <mailto:de...@qqdd.co.uk>> ha scritto:
> Hi Massimo,
>
> Thanks for the interest, and my apologies for the late reply.
>
> I’m not particularly
ommitfest to
> commitfest and never be taken over by anyone?
>
> Massimo.
>
> Il giorno ven 6 mar 2020 alle ore 22:36 Dent John <mailto:de...@qqdd.eu>> ha scritto:
> > On 22 Feb 2020, at 10:38, Dent John wrote:
> >
> >> On 18 Feb 2020, at 03:03
> 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 invasi
> On 22 Feb 2020, at 10:38, Dent John wrote:
>
>> On 18 Feb 2020, at 03:03, Thomas Munro wrote:
>>
>> From the trivialities department, I see a bunch of warnings about
>> local declaration placement (we're still using C90 rules for those by
>> projec
> On 18 Feb 2020, at 03:03, Thomas Munro wrote:
>
> From the trivialities department, I see a bunch of warnings about
> local declaration placement (we're still using C90 rules for those by
> project policy):
>
> refcursor.c:138:3: error: ISO C90 forbids mixed declarations and code
> [-Werror=de
> On 24 Jan 2020, at 08:27, Peter Eisentraut
> wrote:
>
> I definitely want to make it work in a way that does not require writing C
> code. My idea was to create a new type, perhaps called "descriptor", that
> represents essentially a tuple descriptor. (It could be exactly a TupleDesc,
> a
> 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, b
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.
>> [ pip
> On 19 Jan 2020, at 22:30, Dent John wrote:
>
> I have not yet made steps towards documentation, nor yet rebased, so the
> Makefile chunk will probably still fail.
Attached patch addresses these points, so should now apply cleanly agains dev.
I also changed the OID assigned to
> On 11 Jan 2020, at 12:04, Dent John wrote:
>
>> On 10 Jan 2020, at 15:45, Daniel Verite wrote:
>>
>> postgres=# select unnest('c'::refcursor);
>> server closed the connection unexpectedly
>> This probably means the server terminated abn
> On 14 Jan 2020, at 14:53, Daniel Verite wrote:
>
> What is the expected result anyway? A single column with a "record"
> type? FWIW I notice that with plpgsql, this is not allowed to happen:
Hmm. How interesting.
I had not really investigated what happens in the case of a function returning
> On 10 Jan 2020, at 15:45, Daniel Verite wrote:
>
> At a quick glance, I don't see it called in the select-list in any
> of the regression tests. […]
Yep. I didn’t test it because I figured it wasn’t particularly useful in that
context. I’ll add some tests for that too once I get to the root
> On 9 Jan 2020, at 17:43, Daniel Verite wrote:
>
> […]
> (using plain text instead of HTML messages might help with that).
Thanks. I’ll do that next time.
> […]
> * unnest-refcursor-v3.patch needs a slight rebase because this chunk
> in the Makefile fails
> - regexp.o regproc.o ri_triggers
Hi folks,I’ve made a revision of this patch. The significant change is to access the Portal using Portal APIs rather than through SPI. It seems the persisted state necessary to survive being used to retrieve a row at a time inside an SRF just isn’t a good fit for SPI. It turned out there was upstre
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 retu
>> 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 some
(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 are
> On 8 Oct 2019, at 11:33, Nikolay Shaplov wrote:
>
> Whoa-whoa!
>
> I am not inventing something new here. Same code is already used in brin
> (brin.c:820), gin (ginutils.c:602) and gist (gistutils.c:909) indexes. I've
> just copied the idea, to do all index code uniform.
>
> This does not m
Hi Nikolay,
I like the new approach. And I agree with the ambition — to split out the
representation from StdRdOptions.
However, with that change, in the AM’s *options() function, it looks as if you
could simply add new fields to the relopt_parse_elt list. That’s still not
true, because parseR
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 same
On 21 Jul 2019, at 22:54, Tom Lane wrote:
>
> 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
Hi folks,Prompted originally by a post by Roman Pekar [1], I wanted to share a revised version of a patch that allows REFCURSOR results to be consumed as data in a regular SQL query as well as my thoughts on how to improve the area as a whole.In order to be clear about the purpose and how I see it
On 19 Aug 2019, at 15:16, Roman Pekar wrote:Hi, John,I think you've outlined the problem and possible solutions quite well. It's great to see that the goal might be not that far from implementing.
Thanks for the prompt, Roman. I meant to have a bit of a play, and your message
Hi Tom,
> On 25 Jul 2019, at 14:25, Tom Lane wrote:
>
> Please explain yourself. InitPlans will, as a rule, get stuck into the
> same place in the plan tree regardless of which paths are chosen; that's
> why we need not consider them in path cost comparisons.
Ah that’s true. I didn’t realise t
Hi folks,
I’ve run into a planning conundrum with my query rewriting extension for MVs
when attempting to rewrite a RECURSIVE CTE.
RECURSIVE CTEs are expensive — and presumably tricky to optimise — and so a
good use case for query rewrite against an MV; all the more so if Yugo’s
Incremental Vi
12 Jul 2019, at 15:13, Nikolay Shaplov wrote:
>
> В письме от четверг, 4 июля 2019 г. 19:44:42 MSK пользователь Dent John
> написал:
>> Hi Nikolay,
>>
>> I have had a crack at re-basing the current patch against 12b2, but I didn’t
>> trivially succeed.
>>
Hi Roman, Pavel,
I was interested in this post, as it’s a topic I’ve stumbled upon in the past.
There are two topics at play here:
1. The ability to flexibly craft queries from procedural language functions
2. Support for pipelined access to SETOF/TABLEs from procedural language
functions
Po
Hi Nikolay,
I have had a crack at re-basing the current patch against 12b2, but I didn’t
trivially succeed.
It’s probably more my bodged fixing of the rejections than a fundamental
problem. But I now get compile fails in — and seems like only — vacuum.c.
gcc -Wall -Wmissing-prototypes -Wpointe
Hi Nikolay,
> On 3 Apr 2019, at 20:54, Nikolay Shaplov wrote:
>
> В письме от вторник, 19 марта 2019 г. 16:09:13 MSK пользователь Michael
> Paquier написал:
>
>> Thanks for doing the effort to split that stuff. This looks like an
>> interesting base template for anybody willing to look after
ote:
>
> Dent John writes:
>> I guess my question is, and I correctly understanding that reloptions are
>> basically off-limits to EXTENSIONS?
>
> IIRC that's basically true. There's a lot of dissatisfaction with the
> current implementation of reloptions,
Hi folks,
I’ve been paying my query-rewrite for MVs EXTENSION a bit of attention
recently, and I was looking at how to enable people to turn it on and off
without requiring a user of it to get too much into it’s guts.
However, the add_X_reloption() APIs seems to need to be paired with a change
Hi Nico,
By the way, I do agree with your point about MERGE — if we can factor MV
updates in that fashion, it will certainly save.
I didn’t reply immediately because your point caught me off guard:
> […] If you look at my
> sketch for how to do it, you'll notice that many of the sorts of queri
Hi Nico,
I’m pretty impressed anything in this space can be written entirely in PlPGQSL!
If you did integrate your implementation, it would be easy for my Extension to
read from a table other than the one which it gets the MV definition from...
Although having said that, if you went down the ro
I commented to Corey (privately) that, while my rewrite extension has gotten me
a server that responds quickly to aggregate queries, the constant need to
refresh the supporting MVs means the system’s load average is constant and much
higher than before. I’m happy with the tradeoff for now, but i
Hi,
I wanted to share the project I've been working on which dynamically rewrites
queries to target materialized views when views are available that can satisfy
part of a query with lower cost plans.
I embarked upon as an interesting side project. It took me a bit more time than
I anticipated,
37 matches
Mail list logo