Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hWvM0-0002S8-69 for pgsql-hackers@arkaria.postgresql.org; Sat, 01 Jun 2019 04:10:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hWvLy-0006FV-Jn for pgsql-hackers@arkaria.postgresql.org; Sat, 01 Jun 2019 04:10:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hWvLy-0006F5-7K for pgsql-hackers@lists.postgresql.org; Sat, 01 Jun 2019 04:10:46 +0000 Received: from smtp03.optiver.com ([195.246.114.70]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hWvLr-0006LW-G3 for pgsql-hackers@postgresql.org; Sat, 01 Jun 2019 04:10:45 +0000 Received: from pps.filterd (smtp03.optiver.com [127.0.0.1]) by smtp03.optiver.com (8.16.0.27/8.16.0.27) with SMTP id x5142C4B008632; Sat, 1 Jun 2019 06:10:24 +0200 Received: from opammb0562.comp.optiver.com (opammb0562.comp.optiver.com [10.131.160.2]) by smtp03.optiver.com with ESMTP id 2suey5815s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 01 Jun 2019 06:10:24 +0200 Received: from opammb0561.comp.optiver.com (10.131.160.1) by opammb0562.comp.optiver.com (10.131.160.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 1 Jun 2019 06:10:24 +0200 Received: from opammb0561.comp.optiver.com ([::1]) by opammb0561.comp.optiver.com ([fe80::d550:2c12:6cc:8457%17]) with mapi id 15.00.1263.000; Sat, 1 Jun 2019 06:10:24 +0200 From: Floris Van Nee To: Dmitry Dolgov <9erthalion6@gmail.com>, Kyotaro HORIGUCHI CC: Jeff Janes , Thomas Munro , Jesper Pedersen , Alexander Kuzmenkov , Peter Geoghegan , Tomas Vondra , Thomas Munro , Bhushan Uparkar , PostgreSQL-development , Alexander Korotkov , James Coleman Subject: Re: Index Skip Scan Thread-Topic: Index Skip Scan Thread-Index: AQHVGC8P7+a7QHYc+EyrxQaltQNV5Q== Date: Sat, 1 Jun 2019 04:10:23 +0000 Message-ID: <1559362223126.18661@Optiver.com> References: <2685f020-f302-9bf6-1b5c-ebc2bcebc635@2ndquadrant.com> <20190315.125452.252656146.horiguchi.kyotaro@lab.ntt.co.jp> ,,<1559361698401.22864@Optiver.com> In-Reply-To: <1559361698401.22864@Optiver.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.160.182] x-tm-as-product-ver: SMEX-11.0.0.1284-8.100.1062-24650.004 x-tm-as-result: No--4.274900-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_155936222312618661Optivercom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-01_03:,, signatures=0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --_000_155936222312618661Optivercom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Actually I'd like to add something to this. I think I've found a bug in the= current implementation. Would someone be able to check? Given a table definition of (market text, feedcode text, updated_at timesta= mptz, value float8) and an index on (market, feedcode, updated_at desc) (no= te that this table slightly deviates from what I described in my previous m= ail) and filling it with data. The following query uses an index skip scan and returns just 1 row (incorre= ct!) select distinct on (market, feedcode) market, feedcode from streams.base_price where market=3D'TEST' The following query still uses the regular index scan and returns many more= rows (correct) select distinct on (market, feedcode) * from streams.base_price where market=3D'TEST' It seems that partially filtering on one of the distinct columns triggers i= ncorrect behavior where too many rows in the index are skipped. -Floris --_000_155936222312618661Optivercom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Actually I'd like to add something to this. I think I've found a bug in = the current implementation. Would someone be able to check?

Given a table definition of (market text, feedcode text, updated_at time= stamptz, value float8) and an index on (market, feedcode, updated_at desc) = (note that this table slightly deviates from what I described in my previou= s mail) and filling it with data.


The following query uses an index skip scan and returns just 1 row (inco= rrect!)

select distinct on (market, feedcode) market, feedcode
from streams.base_price
where market=3D'TEST'

The following query still uses the regular index scan and returns many= more rows (correct)
select distinct on (market, feedcode) *
from streams.base_price
where market=3D'TEST'

It seems that partially filtering on one of the distinct columns trigger= s incorrect behavior where too many rows in the index are skipped.


-Floris


--_000_155936222312618661Optivercom_--