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
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 applying random_page_cost to too
11 matches
Mail list logo
