soo little time that you don't see it. This is where wait event
occurence and time accumulation would significantly help, currently we can only
sample the wait event state, and thus much of that is never seen, and thus not
known.
Frits Hoogland
> On 26 Jun 2025, at 08:47, James P
ecord -g, taking the backtrace
with it).
This records (samples) the backtraces of on cpu tasks, from which you then can
derive what they are doing, for which you should see lots of tasks in kernel
space, and what that is, using perf report.
Frits Hoogland
> On 26 Jun 2025, at 04:32, Ja
> On 25 Jun 2025, at 07:59, Laurenz Albe wrote:
>
> On Wed, 2025-06-25 at 11:15 +0800, James Pang wrote:
>> pgv14, RHEL8, xfs , we suddenly see tens of sessions waiting on
>> "DataFileRead" and
>> "extend", it last about 2 seconds(based on pg_stat_activity query) , during
>> the
>> waiting t
just can’t remember them off hand, it’s been a while.Sent from my iPhoneOn Jan 25, 2025, at 12:01 PM, Frits Hoogland wrote:I am looking at whether sampling key database catalog information per second would have any drawback whatsoever.I think you're saying that you think isn't the ca
a given.
Why would per second be too much for locks? Is there overhead to select from
pg_locks, or pg_blocking_pids()?
Again, please realise I am happy and appreciative of the time you take, I am
toying with the above described idea.
Frits Hoogland
> On 25 Jan 2025, at 19:18, Pavel
nice with that?
btw, it's interesting to see that both datfrozenxid and datminmxid are in place
updated, with no read consistency provided.
Frits Hoogland
> On 25 Jan 2025, at 14:32, Pavel Stehule wrote:
>
> Hi
>
> so 25. 1. 2025 v 12:23 odesílatel Frits Hoogland <ma
do not cause any significant resources to be taken?
Thanks,
Frits Hoogland
Michael, can you validate if this is consistently happening for the first
connection after database cluster startup?
Frits
> Op 20 apr 2024 om 04:55 heeft Michal Charemza het
> volgende geschreven:
>
>
> Hi,
>
> We're running PostgreSQL as essentially a data warehouse, and we have a few
>
ion
> , then waiting on "LockManager" LWlock,right?
This is the point: no, it’s not about the same relation.
The LWLock:LockManager is a wait event that is raised when competing for the
LWLock that protects the shared Lock structure, which holds all of the locks of
the database.
LWLock, which will greatly increase the time waiting for it, because the LWLock
can only be released if the task manages to get back on CPU.
Regards,
Frits Hoogland
> On 9 Apr 2024, at 09:54, James Pang wrote:
>
> you mean too many concurrent sessions trying to acquire loc
Hi Maria, could you please run explain analyse for the problem query?
The ‘analyze’ addition will track actual spent time and show statistics to
validate the planner’s assumptions.
Frits Hoogland
> On 27 Dec 2023, at 16:38, Wilson, Maria Louise (LARC-E301)[RSES]
> wrote:
>
>
) have to entered correctly too that have lead
up to a potential generic plan having been chosen.
Frits Hoogland
> On 18 Nov 2023, at 12:13, James Pang (chaolpan) wrote:
>
> Looks like it's not sql issue, manually running still use prepared statements
> and
something material did change with JDBC
for your old and new JDBC versions, I do believe the prepareThreshold did not
change.
Frits Hoogland
> On 5 Nov 2023, at 20:47, David Rowley wrote:
>
> On Mon, 6 Nov 2023 at 08:37, Abraham, Danny wrote:
>>
>> Both plans
Are you absolutely sure that the two databases you’re comparing the executing
with are identical, and that the objects involved in the query are physically
and logically identical?
The planning is done based on cost/statistics of the objects. If the statistics
are different, the planner may com
data increases over time, and thus more blocks are needed to
be read because more rows are stored that needs scanning to get a result, then
the latency will increase.
Frits Hoogland
> On 22 Sep 2023, at 10:35, Koen De Groote wrote:
>
> Alright.
>
> So, if I want to speed up t
skipped, it cannot choose another
plan anymore for that named statement for the lifetime of the prepared
statement in that backend, unless the backend is instructed explicitly to not
to use the generic statement.
Frits Hoogland
> On 11 Sep 2023, at 10:13, Laurenz Albe wrote:
>
&g
16 matches
Mail list logo
