Le 26/06/2018 à 16:43, Alvaro Herrera a écrit :
> On 2018-Jun-25, Tom Lane wrote:
>
>> Alvaro Herrera writes:
>>> On 2018-Jun-18, David Rowley wrote:
I've attached a patch which cleans up my earlier version and moves the
setup of the append_rel_array into its own function instead of
Le 18/06/2018 à 10:46, David Rowley a écrit :
> On 12 June 2018 at 01:49, Robert Haas wrote:
>> On Fri, Jun 8, 2018 at 3:08 PM, Tom Lane wrote:
>>> Robert Haas writes:
That being said, I don't mind a bit if you want to look for further
speedups here, but if you do, keep in mind that
Le 30/05/2018 à 03:57, David Rowley a écrit :
> On 26 May 2018 at 09:17, Tom Lane wrote:
>> I'm inclined to think that we should flush find_appinfos_by_relids
>> altogether, along with these inefficient intermediate arrays, and instead
>> have the relevant places in adjust_appendrel_attrs call
Le 25/05/2018 à 16:49, Robert Haas a écrit :
> On Fri, May 25, 2018 at 10:30 AM, Thomas Reiss
> wrote:
>> Then I used the following to compare the planning time :
>> explain (analyze) SELECT * FROM t1 WHERE dt = '2018-05-25';
>>
>> With PostgreSQL 10,
Hello,
I spent some time to test the new features on partitioning with the
beta1. I noticed a potentially huge performance regression with
plan-time partition pruning.
To show the issue, I used this DO statement to generate some partitions,
one per day :
DO $$
DECLARE
part_date date;
ddl text
