Re: Planning time is time-consuming

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Mikhail Balayan <mv(dot)balayan(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Subject: Re: Planning time is time-consuming
Date: 2023-09-11 14:27:13
Message-ID: 2563519.1694442433@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> I'm not sure if you're asking for help here because you need planning
> to be faster than it currently is, or if it's because you believe that
> planning should always be faster than execution. If you think the
> latter, then you're mistaken.

Yeah. I don't see anything particularly troubling here. Taking
circa three-quarters of a millisecond (on typical current hardware)
to plan a four-way join on large tables is not unreasonable.
In most cases one could expect the execution of such a query to
take a good bit longer than that. I think the OP is putting too
much emphasis on an edge case where execution finishes quickly
because there are in fact zero rows matching the uuid restriction.

BTW, in addition to the duplicative indexes, I wonder why the
uuid columns being joined on aren't all of "uuid" type. While
I doubt fixing that would move the needle greatly, it still
seems sloppy.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Imre Samu 2023-09-11 15:17:33 Re: Planning time is time-consuming
Previous Message Frits Hoogland 2023-09-11 13:54:59 Re: Planning time is time-consuming