This sounds extremely plausible -- thanks for the tip, Andreas.
Best,
Patrick
On Fri, 7 Sep 2018, 19:20 Andreas Kretschmer,
wrote:
>
> >
> >Intermittently (one or two times a week), all queries on that host are
> >simultaneously blocked for extended periods (10s of seconds).
> >
> >The blocked
Oh, to be clear - I'll be implementing your suggestion regardless, it seems
valuable whether or not it gets me closer to the root cause this time :)
I was just trying to dig into why it may be relevant -- I want to really
get a good grip on the mechanism behind this phenomenon.
Cheers
Patrick
On
padusuma writes:
> I am working on adding support for PostgreSQL database for our application.
> In a lot of our use-cases, data is inserted into temporary tables using
> INSERT INTO statements with bind parameters, and subsequently queries are
> run by joining to these temp tables. Following i
I am working on adding support for PostgreSQL database for our application.
In a lot of our use-cases, data is inserted into temporary tables using
INSERT INTO statements with bind parameters, and subsequently queries are
run by joining to these temp tables. Following is some of the data for these
Hi everybody,
I ran into an issue with using the && array operator on a GIN index of mine.
Basically I have a query that looks like this:
SELECT * FROM example WHERE keys && ARRAY[...];
This works fine for a small number of array elements (N), but gets really slow
as N gets bigger in what appe
On Fri, Sep 7, 2018 at 2:03 PM Patrick Molgaard wrote:
>
> Hi Jeff,
>
> Thanks for your reply. Are locks relevant in this case, though?
>
I don't know, but why theorize when we can know for sure? It at least
invokes VirtualXactLockTableInsert. I don't see how that could block on a
heavyweight
On 09/07/2018 11:12 AM, Andreas Kretschmer wrote:
Intermittently (one or two times a week), all queries on that host are
simultaneously blocked for extended periods (10s of seconds).
The blocked queries are trivial & not related to locking - I'm seeing
slowlogs of the form:
please check if TH
>
>Intermittently (one or two times a week), all queries on that host are
>simultaneously blocked for extended periods (10s of seconds).
>
>The blocked queries are trivial & not related to locking - I'm seeing
>slowlogs of the form:
>
please check if THP are enabled.
Regards, Andreas
--
2
Hi Jeff,
Thanks for your reply. Are locks relevant in this case, though?
To be clear, the slow statements are the first thing happening on the
connection and don't look like they should be acquiring any kind of lock -
eg. 'select version();' also seems to be paused when it occurs.
Or are there s
I have the following tables:
- m(pk bigserial primary key, status text): with a single row
- s(pk bigserial primary key, status text, action_at date, m_fk bigint):
* 80% of the data has action_at between the current date and 1 year ago
and status of E or C
* 20% of the data has action_at b
On Fri, Sep 7, 2018 at 8:00 AM Patrick Molgaard wrote:
> Hi folks,
>
> I've been seeing some curious behaviour on a postgres server I administer.
>
> Intermittently (one or two times a week), all queries on that host are
> simultaneously blocked for extended periods (10s of seconds).
>
> The bloc
Hi folks,
I've been seeing some curious behaviour on a postgres server I administer.
Intermittently (one or two times a week), all queries on that host are
simultaneously blocked for extended periods (10s of seconds).
The blocked queries are trivial & not related to locking - I'm seeing
slowlogs
12 matches
Mail list logo
