Re: [HACKERS] RTE_NAMEDTUPLESTORE, enrtuples and comments
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] RTE_NAMEDTUPLESTORE, enrtuples and comments |
Дата | |
Msg-id | CA+TgmoZMquF15R1m+zNeO=JQ8z3qVo4EDpxjTo18fpo1Xzqkxg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] RTE_NAMEDTUPLESTORE, enrtuples and comments (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: [HACKERS] RTE_NAMEDTUPLESTORE, enrtuples and comments
|
Список | pgsql-hackers |
On Mon, Jun 12, 2017 at 12:04 AM, Thomas Munro <thomas.munro@enterprisedb.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
В списке pgsql-hackers по дате отправления: