pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Paul Ramsey <pramsey@cleverelephant.ca>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Allowing extensions to supply operator-/function-specific info
Date: Wed, 27 Feb 2019 18:40:30 -0500
Message-ID: <15086.1551310830@sss.pgh.pa.us> (raw)
In-Reply-To: <74C11775-67A7-48D2-B1E3-24C52A686F86@cleverelephant.ca>
References: <15193.1548028093@sss.pgh.pa.us>
	<6953.1548297558@sss.pgh.pa.us>
	<6044.1548524131@sss.pgh.pa.us>
	<CA+TgmoYkLjVcbZZ8PYyaCTMYZJCQ8eiod8MSRMDaczjBw=a0bQ@mail.gmail.com>
	<19993.1548697885@sss.pgh.pa.us>
	<CACowWR3jZ4Xo1atU5xTDpEoeeKSw1==sKPhCy3a29HtcE9oQVQ@mail.gmail.com>
	<7671.1551135674@sss.pgh.pa.us>
	<CACowWR3_RyPSYO6a8TVLZ7KnL_rDNh2ywkSTeqFmrAPpP4y6-g@mail.gmail.com>
	<11051.1551139751@sss.pgh.pa.us>
	<CACowWR1ycbLx0t7WwT8uuJnK7E3U+tfzKXBRPaQrgHiCG+hvbA@mail.gmail.com>
	<14747.1551219541@sss.pgh.pa.us>
	<91BAE1F4-7C16-4F87-849F-B01175A8D7D8@cleverelephant.ca>
	<17244.1551226168@sss.pgh.pa.us>
	<74C11775-67A7-48D2-B1E3-24C52A686F86@cleverelephant.ca>

Paul Ramsey <pramsey@cleverelephant.ca> writes:
> The documentation says that a support function should have a signature "supportfn(internal) returns internal”, but doesn’t say which (if any) annotations should be provided. IMMUTABLE? PARALLEL SAFE? STRICT? None? All?

It doesn't matter much given that these things aren't callable from SQL.
The builtin ones are marked immutable/safe/strict, but that's mostly
because that's the default state for builtin functions.  The only one
I'd get excited about is marking it strict if you're not going to check
for a null argument ... and even that is neatnik-ism, not something that
will have any practical effect.

> Variable SupportRequestCost is very exciting, but given that variable cost is usually driven by the complexity of arguments, what kind of argument is the SupportRequestCost call fed during the planning stage? Constant arguments are pretty straight forward, but what gets sent in when a column is one (or all) of the arguments? 

You'll see whatever is in the post-constant-folding parse tree.  If it's a
Const, you can look at the value.  If it's a Var, you could perhaps look
at the pg_statistic info for that column, though whether that would give
you much of a leg up for cost estimation is hard to say.  For any sort of
expression, you're probably going to be reduced to using a default
estimate.  The core code generally doesn't try to be intelligent about
anything beyond the Const and Var cases.

			regards, tom lane




view thread (38+ messages)  latest in thread

Message-ID: <15086.1551310830@sss.pgh.pa.us>
Permalink:  ../15086.1551310830@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/15086.1551310830@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, pramsey@cleverelephant.ca, pgsql-hackers@lists.postgresql.org
  Subject: Re: Allowing extensions to supply operator-/function-specific info
  In-Reply-To: <15086.1551310830@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox