Re: [PATCH] Equivalence Class Filters

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Equivalence Class Filters
Date: 2015-12-07 15:54:03
Message-ID: 7041.1449503643@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> On 12/6/15 10:38 AM, Tom Lane wrote:
>> I said "in most cases". You can find example cases to support almost any
>> weird planner optimization no matter how expensive and single-purpose;
>> but that is the wrong way to think about it. What you have to think about
>> is average cases, and in particular, not putting a drag on planning time
>> in cases where no benefit ensues. We're not committing any patches that
>> give one uncommon case an 1100X speedup by penalizing every other query 10%,
>> or even 1%; especially not when there may be other ways to fix it.

> This is a problem that seriously hurts Postgres in data warehousing
> applications.

Please provide some specific examples. I remain skeptical that this
would make a useful difference all that often in the real world ...
and handwaving like that does nothing to change my opinion. What do
the queries look like, and why would deducing an extra inequality
condition help them?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2015-12-07 16:27:53 Re: [PATCH] Equivalence Class Filters
Previous Message Jim Nasby 2015-12-07 15:35:30 Re: [PATCH] Equivalence Class Filters