Re: How to hint 2 coulms IS NOT DISTINCT FROM each other

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Kim Rose Carlsen <krc(at)hiper(dot)dk>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: How to hint 2 coulms IS NOT DISTINCT FROM each other
Date: 2016-11-01 13:13:39
Message-ID: CAHyXU0z4HzDoUTxQiN2LHn02F+WR+hXzb=M7VseStK59-+A+cw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Oct 31, 2016 at 9:28 AM, Kim Rose Carlsen <krc(at)hiper(dot)dk> wrote:
> On Sat, Oct 29, 2016 at 8:27 AM, Kim Rose Carlsen <krc(at)hiper(dot)dk> wrote:
>
>> > I have tried creating a function called
>> > zero_if_null(int) : int that just select COALESCE($1, 0)
>> > and adding a index on (zero_if_null(customer_id)) on table that contains
>> > customer_id. The only thing I get from is the planner now only knows how
>> > to
>> > compare customer_id, but it still doesn't know that they are of same
>> > value,
>> > only I know that and I want to declare it for the planner.
>
>
>> Well, the *behavior* is mandated by the sql standard. Our
>> implementation is slow however.
>
> Sorry I'm not following, what behavior is mandated by the sql standard?

The semantics of IS DISTINCT FROM, basically, equality with special
consideration for nulls.

> But I'm not sure I can mentally accept an unfilled value should not be
> null (eg. 0, '', '0000-01-01'). But I can see how the equals operator will
> work well with this.

Yeah, this is a dubious tactic and I would normally only consider
using it for surrogate identifiers.

> It might raise another problem, that the nulls are generated through LEFT
> JOINS where now rows are defined. Then the 0 or -1 value need to be
> a computed value. Won't this throw of index lookups? (I might be
> more confused in this area).

Not following this. BTW, if you want a fast plan over the current
data without consideration of aesthetics, try this:

CREATE VIEW view_circuit_with_status AS (
SELECT r.*,
s.circuit_status,
s.customer_id AS s_customer_id,
p.line_speed,
p.customer_id AS p_customer_id
FROM view_circuit r
JOIN view_circuit_product_main s
ON r.circuit_id = s.circuit_id
AND r.customer_id, s.customer_id
JOIN view_circuit_product p
ON r.circuit_id = p.circuit_id
AND r.customer_id, s.customer_id
UNION ALL SELECT r.*,
s.circuit_status,
s.customer_id AS s_customer_id,
p.line_speed,
p.customer_id AS p_customer_id
FROM view_circuit r
JOIN view_circuit_product_main s
ON r.circuit_id = s.circuit_id
AND r.customer_id IS NULL
AND s.customer_id IS NULL
JOIN view_circuit_product p
ON r.circuit_id = p.circuit_id

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2016-11-01 13:55:03 Re: Turning slave into a master - PostgreSQL 9.2
Previous Message Francisco Olarte 2016-11-01 10:23:04 Re: Turning slave into a master - PostgreSQL 9.2