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

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-03 21:18:27
Message-ID: CAKJS1f9VMZGfPCDWeuLoD1rgvTr5JzGLh7vc4YWQCSDrmRCKbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4 May 2016 at 02:10, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> There are probably a few reasonably simple things we could do - e.g. ignore
> foreign keys with just a single column, as the primary goal of the patch is
> improving estimates with multi-column foreign keys. I believe that covers a
> vast majority of foreign keys in the wild.
>
> If that's deemed insufficient, we'll have to resort to a more complex
> improvement, perhaps something akin to the cache proposed in in the unijoin
> patch. But if that's required, that's 9.7 material.

I had thought that if we had a hashtable of rel OIDs which belong to
relations with has_eclass_joins == true, then we could just skip
foreign keys where the confrelid is not in the hashtable. Perhaps that
could be optimised a bit more and we could have something akin to what
predOK is for IndexOptInfo in ForeignKeyOptInfo which just gets set to
true if the relation referenced by the foreign key is in the
simple_rel_array. It's quite likely that if many foreign keys were
used, then the query would have a great number of joins, and planning
would be slow anyway.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-05-03 21:23:39 Re: Timeline following for logical slots
Previous Message Ants Aasma 2016-05-03 21:01:20 Re: what to revert