Re: pg9.6 segfault using simple query (related to use fk for join estimates)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Stefan Huehner <stefan(at)huehner(dot)org>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg9.6 segfault using simple query (related to use fk for join estimates)
Date: 2016-05-04 21:52:04
Message-ID: CA+TgmoZX9FZLijtZ7nnEey-SW2hu6CRpKheaOqAXrZtjNBywyg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 4, 2016 at 5:51 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, May 4, 2016 at 2:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I spent some time trying to make a test case that was impossibly slow,
>> without any really impressive result: I saw at most about a 25% growth in
>> planning time, for a 27-way join with one or two foreign keys per table.
>> I noted however that with a simple FROM list of tables, you don't really
>> get the full force of the combinatorial explosion, because
>> join_search_one_level prefers to generate left-deep trees first, and so
>> the first creation of a given joinrel is always N left-side rels against 1
>> right-side rel, causing the second level of looping to always iterate just
>> once. (GEQO behaves likewise, I think.) I spent a little time trying to
>> devise join order constraints that would result in a lot of high-level
>> joinrels being formed with many relations on both sides, which would cause
>> both of the second and third levels to iterate O(N) times not just once.
>> I didn't have much luck, but I have zero confidence that our users won't
>> find such cases.
>
> I'

Well, that wasn't my best-ever email to the list. Sigh.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-05-04 21:56:21 Re: pg_dump broken for non-super user
Previous Message Robert Haas 2016-05-04 21:51:39 Re: pg9.6 segfault using simple query (related to use fk for join estimates)