Re: Why is NULL not indexable?
От | Daniel Åkerud |
---|---|
Тема | Re: Why is NULL not indexable? |
Дата | |
Msg-id | 004601c0fe5e$c6848b50$c901a8c0@automatic100 обсуждение исходный текст |
Ответ на | Why is NULL not indexable? (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Why is NULL not indexable?
|
Список | pgsql-general |
I was thinking about what this actually meant and came to the conclusion that having SELECT * FROM foo WHERE bar IS NULL would always result in a sequential scan. Or does it mean anything else? Daniel Åkerud > > I can't work out what the 'strategy' bit refers to. All I can find in the > > source code is references to tables of magic numbers. I guess what I really > > want to know is, how hard would it be to fix? > > I believe the main problem is that IS NULL and IS NOT NULL are not > operators (they don't have pg_operator entries), and all of the planning > and indexscan execution machinery is designed around operators. Binary > operators, at that. > > It's possible that this could be hacked around by creating dummy > pg_operator entries for them, but my bet is that cleaning up the loose > ends and no-longer-valid coding assumptions would be a nontrivial task. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >
В списке pgsql-general по дате отправления: