-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of David G Johnston
Sent: Friday, September 12, 2014 12:45 PM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] weird execution plan
Huang, Suya wrote
> Can
From: Jeff Janes [mailto:jeff.ja...@gmail.com]
Sent: Friday, September 12, 2014 4:09 AM
To: Matheus de Oliveira
Cc: Huang, Suya; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] how to change the provoke table in hash join
On Thu, Sep 11, 2014 at 7:09 AM, Matheus de Oliveira
mailto:matiol
Huang, Suya wrote
> Can someone figure out why the first query runs so slow comparing to the
> second one? They generate the same result...
Try: EXPLAIN (ANALYZE, BUFFERS)
I believe you are only seeing caching effects.
David J.
--
View this message in context:
http://postgresql.1045698.n5.n
Hi,
Can someone figure out why the first query runs so slow comparing to the
second one? They generate the same result...
dev=# explain analyze select count(distinct wid) from terms_weekly_20140503 a
join port_terms b on a.term=b.terms;
On Thu, Sep 11, 2014 at 7:09 AM, Matheus de Oliveira <
matioli.math...@gmail.com> wrote:
>
> On Wed, Sep 10, 2014 at 10:05 PM, Huang, Suya
> wrote:
>
>> --plan 1, 10 seconds were spent on sequential scan on term_weekly table.
>>
>>
>>
>> dev=# explain analyze select distinct cs_id from lookup_we
On Wed, Sep 10, 2014 at 10:05 PM, Huang, Suya
wrote:
> --plan 1, 10 seconds were spent on sequential scan on term_weekly table.
>
>
>
> dev=# explain analyze select distinct cs_id from lookup_weekly n inner
> join term_weekly s on s.b_id=n.b_id and s.date=n.date where term in
> ('cat'::text);
>
