Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

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 aband

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

m commitfest 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

Re: The flinfo->fn_extra question, from me this time.

> 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

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

> 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 >> project pol

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

> 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 >

Re: polymorphic table functions light

> 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, >

Re: The flinfo->fn_extra question, from me this time.

> 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,

Re: The flinfo->fn_extra question, from me this time.

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

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

> 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 assigne

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

> 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 abnormall

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

> 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

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

> 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

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

> 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

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

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

Re: The flinfo->fn_extra question, from me this time.

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

Re: The flinfo->fn_extra question, from me this time.

>> 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

Re: The flinfo->fn_extra question, from me this time.

> 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

Re: The flinfo->fn_extra question, from me this time.

(And here’s aforementioned attachment… doh.) pipeline-functionscan-v2.patch Description: Binary data

Re: The flinfo->fn_extra question, from me this time.

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

Re: [PATCH] Do not use StdRdOptions in Access Methods

> 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

Re: [PATCH] Do not use StdRdOptions in Access Methods

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

Re: The flinfo->fn_extra question, from me this time.

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

[WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

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

Re: (select query)/relation as first class citizen

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

Re: add_path() for Path without InitPlan: cost comparison vs. Paths that require one

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

add_path() for Path without InitPlan: cost comparison vs. Paths that require one

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

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

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. >&g

Re: (select query)/relation as first class citizen

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

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

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

Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method

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

Re: Use of reloptions by EXTENSIONs

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, although I

Use of reloptions by EXTENSIONs

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

Re: Query Rewrite for Materialized Views (Postgres Extension)

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

Re: Query Rewrite for Materialized Views (Postgres Extension)

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

Re: Query Rewrite for Materialized Views (Postgres Extension)

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

Query Rewrite for Materialized Views (FDW Extension)

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