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 ordering to satisfy t
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
oducerCodeOfRecordID = $13) OR (gRoot.PolicyID IN
(
SELECT gRoot2.ID col0
FROM pc_policy gRoot2
WHERE
gRoot2.ProducerCodeOfServiceID = $
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
"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édéric
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
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, Dec 8, 2023 at
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 c
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
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
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
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:
> >>> B
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
13 matches
Mail list logo
