From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Siraj G <tosiraj(dot)g(at)gmail(dot)com> |
Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Need assistance in converting subqueries to joins |
Date: | 2024-09-20 04:48:05 |
Message-ID: | 2359011.1726807685@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Siraj G <tosiraj(dot)g(at)gmail(dot)com> writes:
> Please find below the query in the format and its execution plan:
[ blink... ] I'm not sure what you are using there, but it is
*not* Postgres. There are assorted entries in the execution
plan that community Postgres has never heard of, such as
> -> Remove duplicate (P0, IS_SEC_FILT) rows using temporary table
> (weedout) (cost=2085.53 rows=1988) (actual time=0.321..22600.652
> rows=10298 loops=1)
> -> Single-row index lookup on P0 using IS_PROJ_PK
> (IS_PROJ_GUID=T0.IS_PROJ_GUID, IS_REPOSITORY_ID=R0.REP_ID) (cost=0.63
> rows=1) (actual time=0.000..0.000 rows=1 loops=50)
Maybe this is RDS, or Aurora, or Greenplum, or one of many other
commercial forks of Postgres? In any case you'd get more on-point
advice from their support forums than from the PG community.
It looks like this is a fork that has installed its own underlying
table engine, meaning that what we know about performance may not
be terribly relevant.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lok P | 2024-09-20 05:02:59 | Re: How batch processing works |
Previous Message | Siraj G | 2024-09-20 04:28:12 | Re: Need assistance in converting subqueries to joins |