Sumeet Shukla 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
Yes, but when I actually execute the query in pgAdmin3, it takes exactly
the same time of 19.5 secs.
How is that possible?
Thanks & Regards,
Sumeet Shukla
On Thu, Jun 22, 2017 at 7:54 PM, Dave Stibrany wrote:
> The numbers you posted look exactly as I would expect. The first read hits
> disk a
The numbers you posted look exactly as I would expect. The first read hits
disk and takes 108ms, the second read hits the cache and takes 27ms.
On Thu, Jun 22, 2017 at 8:40 PM, Sumeet Shukla
wrote:
> Both the first run and subsequent run takes same amount of time.
>
> *First Run:*
>
> "Seq Scan
Both the first run and subsequent run takes same amount of time.
*First Run:*
"Seq Scan on d_payer (cost=0.00..8610.40 rows=121788 width=133) (actual
time=8.760..98.582 rows=121788 loops=1)"
" *Buffers: shared read=2521*"
"Planning time: 16.820 ms"
"Execution time: 108.626 ms"
*Second Run:*
"S
