e are capturing the plans via auto_explain and limited to the explain
options available with that path. Is there anything in the plan that would
tell us if the execution used a cached plan? (My manual explains does not
use a prepare.)
Thanks, Jerry
On Thu, Jul 17, 2025 at 8:10 PM Tom Lane wrote:
&g
n Thu, Jul 17, 2025 at 7:07 PM Tom Lane wrote:
> Jerry Brenner writes:
> > We are on Postgres 15.5 (Aurora) and capturing query plans via
> > auto_explain. We are seeing a large number of query plans for 2 queries
> > that have 12 tables. Every fast (or "fast enough&
We are on Postgres 15.5 (Aurora) and capturing query plans via
auto_explain. We are seeing a large number of query plans for 2 queries
that have 12 tables. Every fast (or "fast enough") plan has a left deep
tree and every slow plan has a bushy tree. Is there a way to determine if
a plan was gen
While applying transitivity to non-equality conditions is less frequently
beneficial than applying it to equality conditions, it can be very helpful,
especially with third party apps and dynamically changing data. One
possible implementation to avoid the mentioned overhead would be to mark
the int
I/O Timings: read=8160.350
Planning time: 2.209 ms
Execution time: 87705.116 ms
Thanks,
Jerry
On Wed, Jan 17, 2024 at 6:39 AM Jerry Brenner
wrote:
> We are on 13.9.
> I'm wondering why a sort is required for this query, as the index should
> be providing the required o
We are on 13.9.
I'm wondering why a sort is required for this query, as the index should be
providing the required ordering to satisfy the ORDER BY clause. Does it
have to do with the IS NULL predicate on the leading key column in the
index?
There's an index, job_u_closedate_g9cdc6ghupib, on pc_j
poraryBranch = false AND ( ( (
(gRoot.ProducerCodeOfRecordID = $13) OR (gRoot.PolicyID IN
(
SELECT gRoot2.ID col0
FROM pc_policy gRoot2
WHERE
We are currently on 13.9. For each of the questions, I'd also like to know
if anything has changed in that area in later releases.
NOTE: We are capturing all explain plans via auto_explain and storing them
in a database table. One of our longer term goals is to build the
relationship between quer
"Actual Loops": 1,
"Index Cond": "(*(id = ANY ($2)) AND*
(retired = 0) AND (temporarybranch = false))",
Here's the screenshot again:
[image: image.png]
Thanks,
Jerry
On Wed, Dec 20, 2023 at 10:32 AM Fr
The attached query plan is from 11.
We are getting Merge Joins on both sides of the UNION. In both cases, the
first node under the Merge Join returns 0 rows but the other side of the
Merge Join (the one being sorted) is executed and that's where all of the
time is spent.
On the surface, I don't s
at the data is skewed. pc_message
contains messages to be sent to external systems and hence is a volatile
table and the data in the DestinationID column can be highly skewed. In
theory, could using a constant instead of a bind variable for this
predicate help the optimizer?
Thanks,
Jerry
On Fri,
gh to seem like they should stay in the cache. The addition of
the new timestamp columns in pg_stat_statements in 17 will also help us get
a better sense of how long the query had been in the cache.
On Fri, Dec 8, 2023 at 4:44 PM Tom Lane wrote:
> Jerry Brenner writes:
> > We are curre
We are currently on 13. We are capturing the explain plans for query
executions taking 1 second or longer and storing the json files. We are
most of the way through implementing a home grown solution to generate a
consistent hash value for a query plan, so we can find queries with
multiple plans.
Is there any documentation on the semantics of $ variables in json explain
plans for both InitPlans and SubPlans in 13?
I'm trying to understand the attached json file.
- It looks like $0 represents the value from the outer query block when
the correlated subquery is evaluated
- It looks
It would be helpful if a timestamp column was added to pg_stat_statements
to denote when a query entered the view. This would make it easier to tell
how frequently a query is being executed (100,000 times since a specific
timestamp vs 100,000 times since the execution stats were last reset.)
I re
s changing over time, why some executions are more
expensive than others, ...
Thanks,
Jerry
On Mon, Dec 4, 2023 at 7:29 PM Tom Lane wrote:
> Michael Paquier writes:
> > On Mon, Dec 04, 2023 at 09:57:24AM -0500, Tom Lane wrote:
> >> Jerry Brenner writes:
> >
We are currently on Postgres 13.9 (and will be moving to later releases).
We are capturing json explain plans and storing them in a database table.
We can tell that there are different plans for some queries, but that's a
very labor intensive process - we'd rather do this using SQL and comparing
co
17 matches
Mail list logo
