Re: Remove lossy-operator RECHECK flag?
От
Heikki Linnakangas
Тема
Re: Remove lossy-operator RECHECK flag?
Дата
Msg-id
4803A77C.90506@enterprisedb.com
Ответ на
Re: Remove lossy-operator RECHECK flag? (Tom Lane)
Список
Дерево обсуждения
Remove lossy-operator RECHECK flag? Tom Lane <tgl@sss.pgh.pa.us>
Re: Remove lossy-operator RECHECK flag? "Guillaume Smet" <guillaume.smet@gmail.com>
Re: Remove lossy-operator RECHECK flag? Tom Lane <tgl@sss.pgh.pa.us>
Re: Remove lossy-operator RECHECK flag? "Guillaume Smet" <guillaume.smet@gmail.com>
Re: Remove lossy-operator RECHECK flag? Heikki Linnakangas <heikki@enterprisedb.com>
Re: Remove lossy-operator RECHECK flag? Teodor Sigaev <teodor@sigaev.ru>
Re: Remove lossy-operator RECHECK flag? Tom Lane <tgl@sss.pgh.pa.us>
Re: Remove lossy-operator RECHECK flag? Teodor Sigaev <teodor@sigaev.ru>
Re: Remove lossy-operator RECHECK flag? Tom Lane <tgl@sss.pgh.pa.us>
Re: Remove lossy-operator RECHECK flag? Tom Lane <tgl@sss.pgh.pa.us>
Re: Remove lossy-operator RECHECK flag? Teodor Sigaev <teodor@sigaev.ru>
Re: Remove lossy-operator RECHECK flag? Tom Lane <tgl@sss.pgh.pa.us>
Re: Remove lossy-operator RECHECK flag? Heikki Linnakangas <heikki@enterprisedb.com>
Re: Remove lossy-operator RECHECK flag? Gregory Stark <stark@enterprisedb.com>
Re: Remove lossy-operator RECHECK flag? Tom Lane <tgl@sss.pgh.pa.us>
Tom Lane wrote: > Teodor Sigaev writes: >>> By the argument that it's better to break things obviously than to >>> break them subtly, risking case 4 seems more attractive than risking >>> case 2. > >> The single thought is: usually, it's very hard to see that query returns more >> results that it should be. It doesn't matter for fulltext search (and it has >> very good chance to stay unnoticed forever because wrong rows will be sorted >> down by ranking function, although performance will decrease. > > Hmm ... that's a good point. And the performance loss that I'm > complaining about is probably not large, unless you've got a *really* > expensive operator. Maybe we should leave it as-is. > > Anybody else have an opinion? Better slow than wrong in this case. The "better to break obviously than subtly" argument doesn't hold here, because "slow" isn't the same as broken, and returning extra incorrect rows isn't "obviously" :-). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления