| 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: | Whole Thread | Raw Message | 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 |