Re: Index on a NULL-value
От | Bruno Wolff III |
---|---|
Тема | Re: Index on a NULL-value |
Дата | |
Msg-id | 20050531033633.GA20015@wolff.to обсуждение исходный текст |
Ответ на | Re: Index on a NULL-value (Tobias Brox <tobias@nordicbet.com>) |
Ответы |
Re: Index on a NULL-value
Re: Index on a NULL-value |
Список | pgsql-performance |
On Tue, May 31, 2005 at 11:21:20 +0800, Tobias Brox <tobias@nordicbet.com> wrote: > [Tobias Brox - Tue at 11:02:07AM +0800] > > test=# explain select * from mock where b is NULL; > > QUERY PLAN > > -------------------------------------------------------------------- > > Seq Scan on mock (cost=100000000.00..100000020.00 rows=6 width=8) > > Filter: (b IS NULL) > > (2 rows) > > (...) > > > ---------------------------(end of broadcast)--------------------------- > > TIP 9: the planner will ignore your desire to choose an index scan if your > > joining column's datatypes do not match > > That tip helped me :-) > > test=# explain select * from mock where (b IS NULL)=true; > QUERY PLAN > > ---------------------------------------------------------------------- > Index Scan using b_is_null on mock (cost=0.00..4.68 rows=1 width=8) > Index Cond: ((b IS NULL) = true) > (2 rows) Looked back at your first example and saw that you didn't use a partial index which is why you had to contort things to make it possible to use an indexed search. (Though the planner really should have done this since all of the rows should be in one disk block and doing an index scan should require doing more disk reads than a sequential scan for the test case you used.) You want something like this: CREATE INDEX b_is_null ON mock(b) WHERE b IS NULL; The advantage is that the index can be a lot smaller than an index over all of the rows in the case where only a small fraction of rows have a null value for b. (If this isn't the case you probably don't want the index.)
В списке pgsql-performance по дате отправления: