On 8 November 2018 at 06:17, Tom Lane wrote:
> Pushed with cosmetic adjustments.
Thanks for adjusting and pushing.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
David Rowley writes:
> [ v2-0001-Calculate-total_table_pages-after-set_base_rel_si.patch ]
Pushed with cosmetic adjustments. The reason it's okay to not check for
appendrels in this loop is now quite different from the reason it was okay
before, so I didn't like the fact that you'd just
On Sat, Oct 13, 2018 at 7:36 David Rowley
wrote:
> On 12 October 2018 at 23:35, Amit Langote
> wrote:
> > On 2018/10/11 13:45, Amit Langote wrote:
> >> On 2018/10/07 17:43, David Rowley wrote:
> >>> Amit Langote has since posted a patch to delay the RangeTblEntry
> >>> creation until after
On 12 October 2018 at 23:35, Amit Langote wrote:
> On 2018/10/11 13:45, Amit Langote wrote:
>> On 2018/10/07 17:43, David Rowley wrote:
>>> Amit Langote has since posted a patch to delay the RangeTblEntry
>>> creation until after pruning. His patch happens to also move the
>>> total_table_pages
On 2018/10/11 13:45, Amit Langote wrote:
> On 2018/10/07 17:43, David Rowley wrote:
>> Amit Langote has since posted a patch to delay the RangeTblEntry
>> creation until after pruning. His patch happens to also move the
>> total_table_pages calculation, but I believe this change should be
>> made
On 2018/10/07 17:43, David Rowley wrote:
> On 6 October 2018 at 18:20, Edmund Horner wrote:
>> David Rowley said:
>>> I am considering this a bug fix, but I'm proposing this for PG12 only
>>> as I don't think destabilising plans in the back branches is a good
>>> idea. I'll add this to the
On 6 October 2018 at 18:20, Edmund Horner wrote:
> David Rowley said:
>> I am considering this a bug fix, but I'm proposing this for PG12 only
>> as I don't think destabilising plans in the back branches is a good
>> idea. I'll add this to the September commitfest.
>
> I played with the new
David Rowley said:
> I believe that we should be delaying the PlannerInfo's
> total_table_pages calculation until after constraint exclusion and
> partition pruning have taken place. Doing this calculation before we
> determine which relations we don't need to scan can lead to
> incorrectly
On Tue, 25 Sep 2018 at 10:23, Edmund Horner wrote:
> I have a small tweak. In make_one_rel, we currently have:
>
> /*
> * Compute size estimates and consider_parallel flags for each base rel,
> * then generate access paths.
> */
> set_base_rel_sizes(root);
>
David Rowley said:
> I believe that we should be delaying the PlannerInfo's
> total_table_pages calculation until after constraint exclusion and
> partition pruning have taken place. Doing this calculation before we
> determine which relations we don't need to scan can lead to
> incorrectly
10 matches
Mail list logo
