Re: [HACKERS] path toward faster partition pruning
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] path toward faster partition pruning |
Дата | |
Msg-id | 20180507075535.GA32161@paquier.xyz обсуждение исходный текст |
Ответ на | Re: [HACKERS] path toward faster partition pruning (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [Suspect SPAM] Re: [HACKERS] path toward faster partition pruning
Re: [HACKERS] path toward faster partition pruning |
Список | pgsql-hackers |
On Mon, May 07, 2018 at 10:37:10AM +0900, Michael Paquier wrote: > On Fri, May 04, 2018 at 12:32:23PM +0300, Marina Polyakova wrote: > > I got a similar server crash as in [1] on the master branch since the commit > > 9fdb675fc5d2de825414e05939727de8b120ae81 when the assertion fails because > > the second argument ScalarArrayOpExpr is not a Const or an ArrayExpr, but is > > an ArrayCoerceExpr (see [2]): > > Indeed, I can see the crash. I have been playing with this stuff and I > am in the middle of writing the patch, but let's track this properly for > now. So the problem appears when an expression needs to use COERCION_PATH_ARRAYCOERCE for a type coercion from one type to another, which requires an execution state to be able to build the list of elements. The clause matching happens at planning state, so while there are surely cases where this could be improved depending on the expression type, I propose to just discard all clauses which do not match OpExpr and ArrayExpr for now, as per the attached. It would be definitely a good practice to have a default code path returning PARTCLAUSE_UNSUPPORTED where the element list cannot be built. Thoughts? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: