Re: Re: performance problems with bulk inserts/updates on tsrange with gist-based exclude constrains

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: pinker <pinker(at)onet(dot)eu>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Re: performance problems with bulk inserts/updates on tsrange with gist-based exclude constrains
Date: 2016-09-22 02:43:50
Message-ID: CAMkU=1wQjF5JuPEPVAhTm4xb6OTO+rGd4qv7iYcNDx3VCDhsbg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Sep 21, 2016 at 2:18 PM, pinker <pinker(at)onet(dot)eu> wrote:

> Jeff Janes wrote
> > Try swapping the order of the columns in the exclude constraint. You
> want
> > the more selective criterion to appear first in the index/constraint.
> > Presumably "key with =" is the most selective, especially if many of your
> > periods are unbounded.
>
> I would not be so sure with that:
>

As a rule, I generally don't spout random nonsense. Or at least, not
without including a disclaimer. I didn't test it on the OPs exact case,
because he has need blessed us with his data or his scripts. But I have
tested it on other data, and it does work.

> http://use-the-index-luke.com/sql/myth-directory/most-selective-first

I don't see how anything there applies to GiST indexes. Indeed, there
doesn't seem to be much there worth reading at all. The only thing vaguely
informative, other than trivia about other RDBMS, is "It’s useless to have
the most selective column of the index on the left if very few queries
filter on it", which is rather obvious, but also obviously does not apply
to this case.

Cheers,

Jeff

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Patrick B 2016-09-22 03:37:18 Extract date from a TIMESTAMP(6) WITHOUT TIME ZONE NOT NULL column
Previous Message Tom Lane 2016-09-22 01:29:43 Re: Unstable C Function