Re: RTE_NAMEDTUPLESTORE, enrtuples and comments

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Subject: Re: RTE_NAMEDTUPLESTORE, enrtuples and comments
Date: 2017-06-13 12:09:08
Message-ID: CA+TgmoZMquF15R1m+zNeO=JQ8z3qVo4EDpxjTo18fpo1Xzqkxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 12, 2017 at 12:04 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> Here are a couple of ways forward that I can see:
>
> 1. Figure out how to get the QueryEnvironment through more of these
> stack frames (possibly inside other objects), so that
> set_namedtuplestore_size_estimates can look up enrtuples by enrname:

If you were going to do this, the thing to do would be to get it
hooked up to the PlannerInfo, possibly via an intermediate hop in the
Query.

> 2. Rip the row estimation out for now, use a bogus hard coded
> estimate like we do in some other cases, and revisit later. See
> attached (including changes from my previous message).
> Unsurprisingly, a query plan changes.

Perhaps this is a silly question, but I don't particularly see what's
wrong with:

3. Do nothing.

If I understand correctly, for the current use of named tuplestores,
the existing code produces correct estimates. If we chose option #1,
that would still be true, but we'd have to change a bunch of code to
get there. If we chose option #2, it would cease to be true. Why not
just leave it alone?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shubham Barai 2017-06-13 13:00:01 GSoC 2017 weekly progress reports (week 2)
Previous Message Robert Haas 2017-06-13 11:55:38 Re: Transactional sequence stuff breaks pg_upgrade