On Fri, 8 May 2020 at 10:00, David G. Johnston
wrote:
>
> On Thu, May 7, 2020 at 11:07 AM Amarendra Konda wrote:
>>
>> EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS) SELECT pa.process_activity_id AS
>> pa_process_activity_id FROM process_activity pa WHERE pa.app_id =
>> '126502930200650' AND pa.c
On Thu, May 7, 2020 at 11:07 AM Amarendra Konda
wrote:
> EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS) SELECT pa.process_activity_id
> AS pa_process_activity_id FROM process_activity pa WHERE pa.app_id =
> '126502930200650' AND pa.created > '1970-01-01 00:00:00' AND EXISTS (
> SELECT 1 FROM proce
"David G. Johnston" writes:
> On Thu, May 7, 2020 at 10:49 AM Amarendra Konda
> wrote:
>> Can you please explain, why it is getting more columns in output, even
>> though we have asked for only one column ?
>> * Output: pa.process_activity_id, pa.process_activity_type, pa.voice_url,
>> pa.process
On Thu, May 7, 2020 at 10:49 AM Amarendra Konda
wrote:
> Can you please explain, why it is getting more columns in output, even
> though we have asked for only one column ?
>
>
>
> * Output: pa.process_activity_id, pa.process_activity_type, pa.voice_url,
> pa.process_activity_user_id, pa.app_id,
Here is my thought on why row is not limiting when joined vs why it is limiting
when not joined.
When not joined and where clause is having IN, it is using index
process_activity_process_instance_id_app_id_created_idx which has columns
process_instance_id, created which is in order by and hence
On 5/7/20 10:49 AM, Amarendra Konda wrote:
Hi David,
Thanks for the reply.This has optimized number of rows.
Yeah, but your execution time has increased an order of magnitude. Not
sure if that is what you want.
Can you please explain, why it is getting more columns in output, even
though
Hi Virendra,
Thanks for your time.
Here is the table and index structure
* process_activity*
Table "public.process_activity"
Column |Type | Modifiers
+-+-
Hi David,
In earlier reply, Over looked another condition, hence please ignore that
one
Here is the correct one with all the needed conditions. According to the
latest one, exists also not limiting rows from the process_activity table.
EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS) SELECT pa.proce
Hi David,
Thanks for the reply.This has optimized number of rows.
Can you please explain, why it is getting more columns in output, even
though we have asked for only one column ?
EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS) SELECT pa.process_activity_id
AS pa_process_activity_id FROM process_
Hi Adrian,
Thanks for the reply. And i have kept latest execution plans, for various
SQL statements ( inner join, sub queries and placing values instead of sub
query) .
As suggested, tried with INNER JOIN, however result was similar to
subquery.
Is there any way we can tell the optimiser to proc
On Thu, May 7, 2020 at 7:40 AM Adrian Klaver
wrote:
> On 5/7/20 4:19 AM, Amarendra Konda wrote:
> > Hi,
> >
> > PostgreSQL version : PostgreSQL 9.6.2 on x86_64-pc-linux-gnu, compiled
> > by gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9), 64-bit
> >
> > We have noticed huge difference interms of execu
On 5/7/20 4:19 AM, Amarendra Konda wrote:
Hi,
PostgreSQL version : PostgreSQL 9.6.2 on x86_64-pc-linux-gnu, compiled
by gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9), 64-bit
We have noticed huge difference interms of execution plan ( response
time) , When we pass the direct values Vs inner qu
Hi,
PostgreSQL version : PostgreSQL 9.6.2 on x86_64-pc-linux-gnu, compiled by
gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9), 64-bit
We have noticed huge difference interms of execution plan ( response time)
, When we pass the direct values Vs inner query to IN clause.
High level details of the us
13 matches
Mail list logo
