From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dheeraj Sonawane <Dheeraj.Sonawane@ethoca.com>
cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>,
        Chandan Sonaye <Chandan.Sonaye@ethoca.com>,
        Abhishek Patil <Abhishek.Patil@ethoca.com>
Subject: Re: Query performance issue
In-reply-to: 
 <DS0PR14MB7157B75FB7BFC4006204DC93F4A42@DS0PR14MB7157.namprd14.prod.outlook.com>
References: 
 <DS0PR14MB7157B75FB7BFC4006204DC93F4A42@DS0PR14MB7157.namprd14.prod.outlook.com>
Comments: In-reply-to Dheeraj Sonawane <Dheeraj.Sonawane@ethoca.com>
	message dated "Wed, 10 Jul 2024 07:11:39 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1734307.1720618807.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 10 Jul 2024 09:40:07 -0400
Message-ID: <1734308.1720618807@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1734308.1720618807%40sss.pgh.pa.us>
Precedence: bulk

Dheeraj Sonawane <Dheeraj.Sonawane@ethoca.com> writes:
> While executing the join query on the postgres database we have observed=
 sometimes randomly below query is being fired which is affecting our resp=
onse time.

> Query randomly fired in the background:-
> SELECT p.proname,p.oid FROM pg_catalog.pg_proc p, pg_catalog.pg_namespac=
e n WHERE p.pronamespace=3Dn.oid AND n.nspname=3D'pg_catalog' AND ( pronam=
e =3D 'lo_open' or proname =3D 'lo_close' or proname =3D 'lo_creat' or pro=
name =3D 'lo_unlink' or proname =3D 'lo_lseek' or proname =3D 'lo_lseek64'=
 or proname =3D 'lo_tell' or proname =3D 'lo_tell64' or proname =3D 'lorea=
d' or proname =3D 'lowrite' or proname =3D 'lo_truncate' or proname =3D 'l=
o_truncate64')

That looks very similar to libpq's preparatory lookup before executing
large object accesses (cf lo_initialize in fe-lobj.c).  The details
aren't identical so it's not from libpq, but I'd guess this is some
other client library's version of the same thing.

> Query intended to be executed:-
> SELECT a.* FROM tablename1 a INNER JOIN users u ON u.id =3D a.user_id IN=
NER JOIN tablename2 c ON u.client_id =3D c.id WHERE u.external_id =3D ? AN=
D c.name =3D ? AND (c.namespace =3D ? OR (c.namespace IS NULL AND ? IS NUL=
L))

It is *really* hard to believe that that lookup query would make any
noticeable difference on response time for some other session, unless
you are running the server on seriously underpowered hardware.

It could be that you've misinterpreted your data, and what is actually
happening is that that other session has completed its lookup query
and is now doing fast-path large object reads and writes using the
results.  Fast-path requests might not show up as queries in your
monitoring, but if the large object I/O is sufficiently fast and
voluminous maybe that'd account for visible performance impact.

>   2.  Is there any way we can suppress this query?

Stop using large objects?  But the alternatives won't be better
in terms of performance impact.  Really, if this is a problem
for you, you need a beefier server.  Or split the work across
more than one server.

			regards, tom lane