On 14 January 2016 at 02:58, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote:
> 13.01.2016 04:27, David Rowley: > >> I've also done some testing: >> >> create table ab (a int, b int); >> insert into ab select a,b from generate_Series(1,10) a(a), >> generate_series(1,10000) b(b); >> set enable_bitmapscan=off; >> set enable_indexscan=off; >> >> select * from ab where a = 1 and b=1; >> a | b >> ---+--- >> 1 | 1 >> (1 row) >> >> set enable_indexscan = on; >> select * from ab where a = 1 and b=1; >> a | b >> ---+--- >> (0 rows) >> >> This is broken. I've not looked into why yet, but from looking at the >> EXPLAIN output I was a bit surprised to see b=1 as an index condition. I'd >> have expected a Filter maybe, but I've not looked at the EXPLAIN code to >> see how those are determined yet. >> > > Hmm... Do you use both patches? > And could you provide index definition, I can't reproduce the problem > assuming that index is created by the statement > CREATE INDEX idx ON ab (a) INCLUDING (b); Sorry, I forgot the index, and yes you guessed correctly about that. The problem only exists without the omit_opclass_4.0.patch and with the covering_unique_4.0.patch, so please ignore. I will try to review the omit_opclass_4.0.patch soon. David -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
