| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, 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 16:04:48 |
| Message-ID: | 23683.1497369888@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jun 13, 2017 at 11:53 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> But it needs to be changeable, unless you like the proposition that we
>> can never replan a query inside a trigger on the basis of new information
>> about how big the transition table is. Even if you're okay with that
>> particular restriction, the NamedTupleStore stuff is supposed to be
>> flexible enough to accommodate other use-cases, and some of them will
>> surely not be okay with an immutable estimate for the store's size.
> Hmm, true. But even if we extracted enrtuples from the
> RangeTbleEntry, there wouldn't be any mechanism to actually trigger
> such a replan, would there?
You're just pointing out that there's a lot of unfinished work around
this mechanism. I don't think anybody has claimed otherwise.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2017-06-13 16:14:07 | Re: Typo in BRIN documentation |
| Previous Message | Bruce Momjian | 2017-06-13 16:04:34 | Re: WIP: Data at rest encryption |