The two constraints that you have specified:
- Very low downtime
- Limited disk space use
conflict rather seriously.
You have (wisely, IMO) excluded the option of using pg_upgrade
with a custom rebuilt Pg, which is the only option I see that'd satisfy both those constraints.
I suspect you'll have to drop the disk space constraint. The only way out of this that I see is to configure Slony-I to replicate from your 8.3 database to a new 9.2 instance deployed either on new storage on the same machine, or on a separate machine. Allow Slony-I to bring the replica up to date, then shut the old server down, disable replication and cut over to the new server. "New server" here can be a new 9.2 cluster running on a different port on the existing server hardware, it doesn't have to be a new physical or virtual machine.
At this point you can use streaming replication - or Slony-I again - to replicate the data back to a 9.2 instance on the original server and fail back to it. The temporary server used for migration can be retired, or (preferably, if it's real hardware) configured to operate as a streaming replication slave and WAL archiving repository for PITR and failover purposes.
Slony-I is a bit of an experience to work with and places some constraints on how you can use the DB (mainly: All DDL must go through Slony, not direct DDL commands), so I recommend taking a dump of the 8.3 server, restoring it to a test workstation, and testing the proposed replication setup there before attempting it in production. You will need to test your application on 9.2 anyway, so this is a good chance to do both. Test it on 8.3-with-slony, and on 9.2.
This might be a good opportunity to see professional support from people who have experience dealing with these issues.
There's a different, simpler, solution for this. Add an argument to function fA
with a default value, for instance: called_from_b BOOLEAN DEFAULT FALSE
. Then, provide that argument when calling fA
from fB
.
I understand that this doesn't directly answer your question, but it does provide a solution for the example usecase that you provide.
Best Answer
Since it changes the actual execution plan, you can tell from the output of
EXPLAIN (ANALYZE, VERBOSE)
(among others): Example:I simplified and adapted the fiddle from my answer you are referring to:
db<>fiddle here
The first function is inlined, hence you see the inlined expression in the output:
The second function is not inlined, hence you see the function call in the output:
To be precise: this shows whether the function has been inlined in the tested query. If it has not, that does not necessarily prove it can't be (under different circumstances).
And the test is not bound to just
IMMUTABLE
functions in any way.