Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Slow update on column that is part of exclusion constraint
From: Evgeniy Shishkin <itparanoia@gmail.com>
In-Reply-To: 
 <CAMjNa7dkzOZeAPfdxXo3Tf604xx-F+iRyX_M+GbvMHws2DtsrA@mail.gmail.com>
Date: Fri, 15 Apr 2016 12:31:59 +0300
Cc: pgsql-performance@postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CECDC931-7183-4A50-9AF9-5188FA68A105@gmail.com>
References: 
 <CAMjNa7ck5JZxooWUsZ_ag71HA=GB_zKzpMOgaFO0Z5+YfEerOA@mail.gmail.com>
 <CAMjNa7e6XeyAue0XEi=Pnc8rRp5qK6RvnTg69woTGTG6zw9rcQ@mail.gmail.com>
 <5C918770-5BC7-43E2-90B1-9A90174370F6@gmail.com>
 <CAMjNa7dkzOZeAPfdxXo3Tf604xx-F+iRyX_M+GbvMHws2DtsrA@mail.gmail.com>
To: Adam Brusselback <adambrusselback@gmail.com>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


> On 14 Apr 2016, at 07:17, Adam Brusselback <adambrusselback@gmail.com> wr=
ote:
>=20
> So fair enough, it does seem to be related to the lookup rather than main=
tenance on the index. I was misguided in my initial assumption.=20=20
>=20
> Spent quite a bit of time trying to come up with a self contained test, a=
nd it seems like I can't make it choose the GiST index unless I remove the =
regular btree index in my test case, though the opposite is true for my tab=
le in production.  Not really sure what that means as far as what I need to=
 do though. I've tried a vacuum full, analyze, rebuild index, drop and re-a=
dd the constraint... It still uses that GiST index for this query.
>=20
> Hell, a sequential scan is a ton faster even.
>=20

As i understand it, postgres needs a way to find rows for update.
In explain analyze you provided, we see that it chose gist index for that.
And that is a poor chose. I think you need a proper btree index for update=
=20
query to work properly fast. Like index on (product_id, company_id, date_ra=
nge) WHERE upper(price_generated_test.active_range) IS NULL.=20


> On Wed, Apr 13, 2016 at 2:54 PM, Evgeniy Shishkin <itparanoia@gmail.com> =
wrote:
>=20
> > On 13 Apr 2016, at 20:14, Adam Brusselback <adambrusselback@gmail.com> =
wrote:
> >
> > Sorry, brain stopped working and I forgot to include the normal info.
> >
> > Postgres version: 9.5.1
> > Hardware: 2 core, 4gb Digital Ocean virtual server
> > OS: Debian
> >
> > explain analyze for an example update:
> > 'Update on price_generated  (cost=3D32.45..644.83 rows=3D1 width=3D157)=
 (actual time=3D29329.614..29329.614 rows=3D0 loops=3D1)'
> > '  ->  Nested Loop  (cost=3D32.45..644.83 rows=3D1 width=3D157) (actual=
 time=3D29329.608..29329.608 rows=3D0 loops=3D1)'
> > '        ->  HashAggregate  (cost=3D32.04..34.35 rows=3D231 width=3D52)=
 (actual time=3D1.137..2.090 rows=3D231 loops=3D1)'
> > '              Group Key: pti.product_id, pti.company_id, pti.date_rang=
e'
> > '              ->  Seq Scan on _prices_to_insert pti  (cost=3D0.00..30.=
31 rows=3D231 width=3D52) (actual time=3D0.060..0.678 rows=3D231 loops=3D1)'
> > '        ->  Index Scan using price_generated_company_product_date_acti=
ve_excl on price_generated  (cost=3D0.41..2.63 rows=3D1 width=3D151) (actua=
l time=3D126.949..126.949 rows=3D0 loops=3D231)'
> > '              Index Cond: (date_range =3D pti.date_range)'
> > '              Filter: ((upper(active_range) IS NULL) AND (pti.product_=
id =3D product_id) AND (pti.company_id =3D company_id))'
> > '              Rows Removed by Filter: 29460'
> > 'Planning time: 3.134 ms'
> > 'Execution time: 29406.717 ms'
>=20
> Well, you see execution time of 30 seconds because there are 231 index lo=
okups,
> each taking 126 ms.
>=20
> And that lookup is slow because of
> Filter: ((upper(active_range) IS NULL) AND (pti.product_id =3D product_id=
) AND (pti.company_id =3D company_id))'
>=20
> Can you provide self-containing example of update?
> I don't see there (upper(active_range) IS NULL condition is coming from.
>=20
> <excl constraint test case.sql>
> --=20
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance


--=20
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance