James Parks writes:
> On Mon, Feb 29, 2016 at 5:22 PM, Tom Lane wrote:
>> The other explain shows a scan of "a" reading about 490k rows and
>> returning 395 of them, so there's a factor of about 200 re-read here.
>> I wonder if the planner should have inserted a materialize node to
>> reduce that
On Sun, Feb 28, 2016 at 2:06 AM, David Rowley
wrote:
> On 27 February 2016 at 11:07, James Parks wrote:
> >
> > CREATE TABLE a (id bigint primary key, nonce bigint);
> > CREATE TABLE b (id bigint primary key, a_id bigint not null);
> > CREATE INDEX a_idx ON b (a_id);
> >
> > The query:
> >
> > S
David Rowley writes:
> On 27 February 2016 at 11:07, James Parks wrote:
>> If you force the query planner to use a merge join on the above query, it
>> takes 10+ minutes to complete using the data as per below. If you force the
>> query planner to use a hash join on the same data, it takes ~200
>
On 27 February 2016 at 11:07, James Parks wrote:
>
> CREATE TABLE a (id bigint primary key, nonce bigint);
> CREATE TABLE b (id bigint primary key, a_id bigint not null);
> CREATE INDEX a_idx ON b (a_id);
>
> The query:
>
> SELECT b.* FROM b JOIN a ON b.a_id = a.id WHERE a.nonce = ? ORDER BY b.id
