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 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
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
>
>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
--
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
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
