Re: Changing SQL Inlining Behaviour (or...?) - Mailing list pgsql-hackers

From Paul Ramsey
Subject Re: Changing SQL Inlining Behaviour (or...?)
Date
Msg-id 64136402-0DAA-496C-BCBE-DCA9184ED923@cleverelephant.ca
Whole thread Raw
In response to Re: Changing SQL Inlining Behaviour (or...?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Changing SQL Inlining Behaviour (or...?)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

> On Feb 3, 2019, at 3:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
>> I've posted some preliminary design ideas at
>> https://www.postgresql.org/message-id/15193.1548028093@sss.pgh.pa.us
>> and
>> https://www.postgresql.org/message-id/15289.1548028233@sss.pgh.pa.us
>> While there's a nontrivial amount of work needed to make that happen,
>> I think it's doable, and it would lead to a significantly better
>> solution than proceeding along the inlining path could do.  My
>> current feeling, therefore, is that we should reject this patch
>> (or at least stick it in the deep freeze) and go work on that plan.
>
> Now that the first of those threads has reached a feature-complete
> state, I feel fairly comfortable in saying that we should drop the
> idea of messing with the inlining heuristics (at least for the
> particular end goal stated in this thread).  So I'm going to go
> close this CF entry as returned-with-feedback.
>
>             regards, tom lane

Hokay… I’ve read through the patch set, applied it and built it, all works. Am starting to try a test implementation in
PostGISland. Robert’s comment about “PostgreSQL magic” is ringing through my head ... Nodes and Ops and Exprs, oh my!
Whatever doesn’t kill me only makes me stronger, right? :) 

P.

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Commit Fest 2019-01 is now closed
Next
From: Jerry Jelinek
Date:
Subject: Re: patch to allow disable of WAL recycling