Re: Bitmap index scans use of filters on available columns
От | Robert Haas |
---|---|
Тема | Re: Bitmap index scans use of filters on available columns |
Дата | |
Msg-id | CA+TgmoY63QSvE-g4k0==NnT8QCMrNxHjnbRuQ55PNNdqTs+X6A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bitmap index scans use of filters on available columns (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: Bitmap index scans use of filters on available columns
|
Список | pgsql-hackers |
On Fri, Nov 6, 2015 at 7:11 PM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: >> I think LEAKPROOF is probably fine for this. How would the new thing >> be different? > > I don't think so - AFAIK "leakproof" is about not revealing information > about arguments, nothing more and nothing less. It does not say whether it's > safe to evaluate on indexes, and I don't think we should extend the meaning > in this direction. That seems like a non-answer answer. Clearly, if a function can leak information about it's arguments, for example by throwing an error, we can't call it on tuples that might not even be visible, or the behavior of the query might be change. So any function that is not leakproof is also not safe for this purpose. Now that doesn't rule out the possibility that the functions for which this optimization is safe are a subset of the leakproof functions - but offhand I don't see why that should be the case. The index tuple is just a tuple, and the values it contains are just datums, no more or less than in a heap tuple. There could be a reason for concern here, but saying that it might not be "safe to evaluate on indexes" just begs the question: WHY wouldn't that be safe? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: