Buffers: shared hit=72620045 read=45,297,330
I/O Timings: read=57,489,958.088
Execution time: 61,141,110.516 ms
If I'm reading this correctly, it took 57M ms out of an elapsed time of 61M
ms to read 45M pages from the filesystem?
If the average service time per sarr is < 5 ms, Is this a case of bl
or a
> self-hostable option.
>
> Patrick
>> On Fri, Sep 14, 2018 at 4:38 PM Fred Habash wrote:
>> Any ideas, please?
>>
>>> On Thu, Sep 13, 2018, 3:49 PM Fd Habash wrote:
>>> In API function may invoke 10 queries. Ideally, I would like to know w
Any ideas, please?
On Thu, Sep 13, 2018, 3:49 PM Fd Habash wrote:
> In API function may invoke 10 queries. Ideally, I would like to know what
> queries are invoked by it and how long each took.
>
>
>
> I’m using pg_stat_statement. I can see the API function statement, but how
> do I deterministi
Thanks.
How do we go about calculating appropriate values for these two parameters ...
> 'NUM_SUBTRANS_BUFFERS'?
TOTAL_MAX_CACHED_SUBXIDS
And do both require a recompile?
-
Thank you.
On Aug 17, 2018, at 2:26 PM, Alvaro Herrera wrote:
>> And as for the recompile, are you thinking 'NUM
era
wrote:
> On 2018-Aug-16, Fred Habash wrote:
>
> > One of our database API's is run concurrently by near 40 sessions. We see
> > all of them waiting back and forth on this wait state.
>
> What version are you running?
>
> > Why is it called Subtrans Control
One of our database API's is run concurrently by near 40 sessions. We see
all of them waiting back and forth on this wait state.
There is one scenario described in some forum where sessions connected a
read-only replica are affected. This does not apply to our use case.
Why is it called Subtrans
Trying to optimize the Elapsed Time (ET) of this query. Currently, it is
hovering around 3 hrs.
Running a 'vaccum analyse' had no effect on ET. Even forcing an
'indexonly' scan by disabling 'enable_seqscan', still around the 3 hrs.
The table is around 4.6B rows,
explain select cit_id, cl_va
