Re: Pull up sublink of type 'NOT NOT (expr)'

From: Alexey Bashtanov <bashtanov(at)imap(dot)cc>
To: Richard Guo <riguo(at)pivotal(dot)io>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Pull up sublink of type 'NOT NOT (expr)'
Date: 2018-10-23 16:39:19
Message-ID: 6c5f1271-b443-c616-8cf8-e7de024dab70@imap.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Richard,

> Currently for quals in the form of "NOT NOT (SubLink)", this SubLink
> would not
> be considered when pulling up sublinks. For instance:
>
> gpadmin=# explain select * from a where NOT NOT (a.i in (select b.i
> from b));
>      QUERY PLAN
> -------------------------------------------------------------
>  Seq Scan on a (cost=51.50..85.62 rows=1005 width=8)
>    Filter: (hashed SubPlan 1)
>    SubPlan 1
>      ->  Seq Scan on b  (cost=0.00..44.00 rows=3000 width=4)
> (4 rows)
>
>
> Should we give it a chance, like the attached does?

Sometimes hashed subplan is faster than hash join and than all the other
options, as it preserves the order.
Using NOT NOT, one can control whether to use it or not:
https://pgblog.bashtanov.com/2017/12/08/double-negative-and-query-performance/
(test case and results in the bottom of the page).

Surely dirty tricks should not be the way to control the planner, but
when breaking them we should probably provide a way to achieve the same
result,
ideally making the planner choose the best plan without hints.

Best,
  Alex

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vaidyanathaswamy, Anandsaikrishnan 2018-10-23 16:46:31 Postgres older version 8.3.7 on ubuntu 14
Previous Message Andres Freund 2018-10-23 14:50:57 Re: Buildfarm failures for hash indexes: buffer leaks