Re: initial pruning in parallel append
От | Tom Lane |
---|---|
Тема | Re: initial pruning in parallel append |
Дата | |
Msg-id | 787365.1691414969@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: initial pruning in parallel append (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: initial pruning in parallel append
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > ... Second, we've generally made a > decision up until now that we don't want to have a hard dependency on > stable functions actually being stable. If they aren't, and for > example you're using index expressions, your queries may return wrong > answers, but you won't get weird internal error messages, and you > won't get a crash. I think the bar for this feature is the same. Yeah, I agree --- wrong answers may be acceptable in such a case, but crashes or unintelligible error messages aren't. There are practical reasons for being tolerant here, notably that it's not that easy for users to get their volatility markings right. In the case at hand, I think that means that allowing workers to do pruning would require hardening the parallel append code against the situation where their pruning results vary. Maybe, instead of passing the pruning results *down*, we could pass them *up* to the leader and then throw an error if they're different? regards, tom lane
В списке pgsql-hackers по дате отправления: