Re: inconsistent results querying table partitioned by date
От | David Rowley |
---|---|
Тема | Re: inconsistent results querying table partitioned by date |
Дата | |
Msg-id | CAKJS1f-fcpjSK=dnsVsXdC-1ZBVCE23Z=Mbev9Go0W27-dAONg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: inconsistent results querying table partitioned by date (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: inconsistent results querying table partitioned by date
|
Список | pgsql-bugs |
On Sat, 18 May 2019 at 09:30, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Since time is growing short before beta1 wrap, I'm going to go ahead > and push this in hopes of getting buildfarm cycles on it. But feel > free to review and look for further improvements. There's plenty > of time to rethink the data-structure details for the v11 backpatch, > also. Thanks for working on this. I did have a look and was a bit disappointed to see the code will end up calling pull_exec_paramids() 3 times for any expression with exec param IDs. I can knock that down to just 2 by caching the exec Param IDs of the used quals in GeneratePruningStepsContext. I imagine you didn't do this since its possible we reject the qual even after has_exec_param is set, but if we just delay recording the param IDs until after we're certain we're using the qual then it should be safe to do this. This also gets rid of the entire get_partkey_exec_paramids() function, so has the additional saving of not looping through all the steps once more. I had thought reducing duplicate work like this was one of the driving factors for this change, although I understand the main one for this was fixing the bug Amit was working on. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-bugs по дате отправления: