From: | Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sumeet Shukla <sumeet(dot)k(dot)shukla(at)gmail(dot)com> |
Cc: | Dave Stibrany <dstibrany(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Dataset is fetched from cache but still takes same time to fetch records as first run |
Date: | 2017-06-23 07:52:59 |
Message-ID: | 1114378459.249712.1498204379460@mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>To: Sumeet Shukla <sumeet(dot)k(dot)shukla(at)gmail(dot)com>
>Cc: Dave Stibrany <dstibrany(at)gmail(dot)com>; pgsql-performance(at)postgresql(dot)org
>Sent: Friday, 23 June 2017, 5:50
>Subject: Re: [PERFORM] Dataset is fetched from cache but still takes same time to fetch records as first run
> Sumeet Shukla <sumeet(dot)k(dot)shukla(at)gmail(dot)com> writes:>
>> Yes, but when I actually execute the query in pgAdmin3, it takes exactly
>> the same time of 19.5 secs.
>
>pgAdmin is well known to be horribly inefficient at displaying large
>query results (and 121788 rows qualifies as "large" for this purpose,
>I believe). The circa-tenth-of-a-second savings on the server side
>is getting swamped by client-side processing.
>
>It's possible that pgAdmin4 has improved matters in this area.
>
It's also possibly time taken for the results to be tranferred over a network if the data is large.
Glyn
From | Date | Subject | |
---|---|---|---|
Next Message | Akihiko Odaki | 2017-06-23 10:31:40 | Inappropriate inner table for nested loop join |
Previous Message | Tom Lane | 2017-06-23 04:50:31 | Re: Dataset is fetched from cache but still takes same time to fetch records as first run |