As I promised at PgConf.eu, here's a follow-up email about PostGIS
parallelism and function inlining (an odd combination, it is true).
So, context:
- We want PostGIS to parallelize more. In order to achieve that we need to
mark our functions with more realistic COSTs. Much much higher COSTs.
- Wh
All,
> So, context:
>
> - We want PostGIS to parallelize more. In order to achieve that we need to
> mark our functions with more realistic COSTs. Much much higher COSTs.
> - When we do that, we hit a different problem. Our most commonly used
> functions, ST_Intersects(), ST_DWithin() are actual
On Mon, Dec 31, 2018 at 2:23 PM Adam Brightwell <
adam.brightw...@crunchydata.com> wrote:
>
> > * Solution #2 - Quick and dirty and invisible. Tom suggested a hack that
> achieves the aims of #1 but without adding syntax to CREATE FUNCTION: have
> the inlining logic look at the cost of the wrapper
>> > * Solution #2 - Quick and dirty and invisible. Tom suggested a hack that
>> > achieves the aims of #1 but without adding syntax to CREATE FUNCTION: have
>> > the inlining logic look at the cost of the wrapper and the cost of
>> > parameters, and if the cost of the wrapper "greatly exceeded"
Adam Brightwell writes:
> I've been working with Paul to create and test a patch (attached) that
> addresses Solution #2. This patch essentially modifies the inlining
> logic to compare the cost of the function with the total cost of the
> parameters. The goal as stated above, is that for these ki
> On Jan 19, 2019, at 12:25 PM, Tom Lane wrote:
>
> Adam Brightwell writes:
>> I've been working with Paul to create and test a patch (attached) that
>> addresses Solution #2. This patch essentially modifies the inlining
>> logic to compare the cost of the function with the total cost of the
Paul Ramsey writes:
> Is there a rule of thumb we can use in costing our wrappers to ensure that
> they always inline?
Not really, which is a weak spot of this whole approach.
In particular, if you just make procost really big, you risk screwing
things up rather badly in cases where inlining f
> "Tom" == Tom Lane writes:
Tom> The other thing we need to consider is whether we need any
Tom> documentation adjustments. I believe that right now, the rules for
Tom> inlining SQL functions are not documented anywhere but the code,
That is correct, though we got so tired of explaining i
I wrote:
> Paul Ramsey writes:
>> Is there a rule of thumb we can use in costing our wrappers to ensure that
>> they always inline?
> Not really, which is a weak spot of this whole approach.
BTW, it suddenly strikes me that at least for the specific cases you've
shown in this thread, worrying
> On Jan 19, 2019, at 5:53 PM, Tom Lane wrote:
>
> I wrote:
>> Paul Ramsey writes:
>>> Is there a rule of thumb we can use in costing our wrappers to ensure that
>>> they always inline?
>
>> Not really, which is a weak spot of this whole approach.
>
> BTW, it suddenly strikes me that at l
Paul Ramsey writes:
> On Jan 19, 2019, at 5:53 PM, Tom Lane wrote:
>> [ maybe what we need is special index operators for extensions ]
> While I’m not 100% sure what this new thing would “look like” there are at
> least a few quirky variations on the pattern you’ve correctly identified. So,
>
I wrote:
> I'll try to sketch up a more concrete plan soon.
I've posted some preliminary design ideas at
https://www.postgresql.org/message-id/15193.1548028...@sss.pgh.pa.us
and
https://www.postgresql.org/message-id/15289.1548028...@sss.pgh.pa.us
While there's a nontrivial amount of work needed
Hi,
On 2019-01-19 20:53:55 -0500, Tom Lane wrote:
> I wrote:
> > Paul Ramsey writes:
> >> Is there a rule of thumb we can use in costing our wrappers to ensure that
> >> they always inline?
>
> > Not really, which is a weak spot of this whole approach.
>
> BTW, it suddenly strikes me that at
> On Jan 21, 2019, at 3:17 PM, Andres Freund wrote:
>
> Hi,
>
> On 2019-01-19 20:53:55 -0500, Tom Lane wrote:
>> I wrote:
>>> Paul Ramsey writes:
Is there a rule of thumb we can use in costing our wrappers to ensure that
they always inline?
>>
>>> Not really, which is a weak spot
Hi,
On 2019-01-21 15:21:29 -0800, Paul Ramsey wrote:
> As a practical matter, most of the exact-test functions have a
> preamble that checks the bbox, so in the seqscan case having the
> operator along for the ride isn’t any advantage. In any event, if we
> do have exact tests w/o a lossy preamble
> On Jan 21, 2019, at 3:27 PM, Andres Freund wrote:
>
> Hi,
>
> On 2019-01-21 15:21:29 -0800, Paul Ramsey wrote:
>> As a practical matter, most of the exact-test functions have a
>> preamble that checks the bbox, so in the seqscan case having the
>> operator along for the ride isn’t any advan
Further question about this ...
I'm thinking about exactly when indxpath.c should interrogate extensions'
planner support functions. Since it'll cost some cycles to look up and
call such functions, we don't want to do it if there's little or no chance
of getting an index match. Currently, what m
I wrote:
> I've posted some preliminary design ideas at
> https://www.postgresql.org/message-id/15193.1548028...@sss.pgh.pa.us
> and
> https://www.postgresql.org/message-id/15289.1548028...@sss.pgh.pa.us
> While there's a nontrivial amount of work needed to make that happen,
> I think it's doable,
> On Feb 3, 2019, at 3:47 PM, Tom Lane wrote:
>
> I wrote:
>> I've posted some preliminary design ideas at
>> https://www.postgresql.org/message-id/15193.1548028...@sss.pgh.pa.us
>> and
>> https://www.postgresql.org/message-id/15289.1548028...@sss.pgh.pa.us
>> While there's a nontrivial amount
Paul Ramsey writes:
> Hokay… I’ve read through the patch set, applied it and built it, all works.
> Am starting to try a test implementation in PostGIS land. Robert’s comment
> about “PostgreSQL magic” is ringing through my head ... Nodes and Ops and
> Exprs, oh my! What ever doesn’t kill me on
> On Feb 5, 2019, at 11:07 AM, Tom Lane wrote:
>
> Paul Ramsey writes:
>> Hokay… I’ve read through the patch set, applied it and built it, all works.
>> Am starting to try a test implementation in PostGIS land. Robert’s comment
>> about “PostgreSQL magic” is ringing through my head ... Node
Paul Ramsey writes:
> So just a meta-comment, this is all very cool and I can see how it will
> help out things like selectivity estimation and tuple return estimation
> for unnest() and generate_series() and even how I could eventually do
> some dynamic costing for some functions, but it’s gettin
> Neglected to include the footnotes...
As I promised at PgConf.eu, here's a follow-up email about PostGIS
parallelism and function inlining (an odd combination, it is true).
So, context:
- We want PostGIS to parallelize more. In order to achieve that we need to
mark our functions with more real
On Fri, Nov 9, 2018 at 11:14 AM Paul Ramsey
wrote:
> > Neglected to include the footnotes...
>
> As I promised at PgConf.eu, here's a follow-up email about PostGIS
> parallelism and function inlining (an odd combination, it is true).
>
> So, context:
>
> - We want PostGIS to parallelize more. In
>
>
>> At pgconf.eu, I canvassed this problem and some potential solutions:
>>
>
I wonder if there is a middle ground between #2 and #3. A proper mechanism
for deduplicating entries might be hard, but on the inlining stage we
already know they're going to get duplicated. Can we make a subplan/late
25 matches
Mail list logo
