On Wed, 1 Dec 2021 09:14:31 -0300
Marcos Pegoraro wrote:
> >
> > I think the reason why we can't update a materialized view directly is
> > because
> > it is basically a "view" and it should not contains any data irrelevant to
> > its
> > definition and underlying tables. If we would have a
On 12/2/21 12:06, Daniel Gustafsson wrote:
On 6 Nov 2021, at 17:20, Tomas Vondra wrote:
On 11/5/21 22:15, Daniel Gustafsson wrote:
...
1651: GROUP BY optimization
===
This is IMO a desired optimization, and after all the heavy lifting by Tomas
the patch seems to be
> On 6 Nov 2021, at 17:20, Tomas Vondra wrote:
>
> On 11/5/21 22:15, Daniel Gustafsson wrote:
>> ...
>> 1651: GROUP BY optimization
>> ===
>> This is IMO a desired optimization, and after all the heavy lifting by Tomas
>> the patch seems to be in pretty good shape.
>
> I
>
> I think the reason why we can't update a materialized view directly is
> because
> it is basically a "view" and it should not contains any data irrelevant to
> its
> definition and underlying tables. If we would have a feature to update a
> materialized view direcly, maybe, it should behave
On Mon, 29 Nov 2021 09:03:06 -0300
Marcos Pegoraro wrote:
> >
> > > 2138: Incremental Materialized View Maintenance
> >
> > I've responded to it in the following thread, and described the recent
> > discussions,
> > current status, summary of IVM feature and design, and past discussions.
> >
>
>
> > 2138: Incremental Materialized View Maintenance
>
> I've responded to it in the following thread, and described the recent
> discussions,
> current status, summary of IVM feature and design, and past discussions.
>
IVM is a wonderful feature, but some features were omitted because of
its
On Fri, 5 Nov 2021 22:15:49 +0100
Daniel Gustafsson wrote:
> 2138: Incremental Materialized View Maintenance
> ===
> There seems to be concensus on the thread that this is a feature that we want,
> and after initial design discussions there seems to be
On Mon, Nov 08, 2021 at 03:07:43PM +0900, Kyotaro Horiguchi wrote:
> I noticed I'm one of the author^^; I'll also look into the comments
> and try to address them.
Cool, thanks. I'll come back to this thread from this point, then.
--
Michael
signature.asc
Description: PGP signature
At Mon, 8 Nov 2021 14:43:43 +0900, Michael Paquier wrote
in
> On Fri, Nov 05, 2021 at 10:15:49PM +0100, Daniel Gustafsson wrote:
> > 2161: standby recovery fails when re-replaying due to missing directory
> > which
> > was removed in previous replay.
> >
On Fri, Nov 05, 2021 at 10:15:49PM +0100, Daniel Gustafsson wrote:
> 2161: standby recovery fails when re-replaying due to missing directory which
> was removed in previous replay.
> =
> Tom and Robert seem to be in
Thanks for the summary.
At Fri, 5 Nov 2021 22:15:49 +0100, Daniel Gustafsson wrote in
> 2490: Make message at end-of-recovery less scary
>
> This thread stalled, but has had recent interest. The patch no longer applies
> so while the patch has
On 2021-Nov-05, Daniel Gustafsson wrote:
> 2716: fix spinlock contention in LogwrtResult
> =
> This addresses a bottleneck which definitely seems like one we want to fix, I
> don't have a hard time imagining it impacting other production usecases then
>
> On 6 Nov 2021, at 02:12, Andy Fan wrote:
>
>> 1741: Index Skip Scan
>> =
>> An often requested feature which has proven hard to reach consensus on an
>> implementation for. The thread(s) have stalled since May,
>
> This statement is not accurate. Peter started a new
> On 6 Nov 2021, at 17:20, Tomas Vondra wrote:
>
> On 11/5/21 22:15, Daniel Gustafsson wrote:
>> ...
>> 1651: GROUP BY optimization
>> ===
>> This is IMO a desired optimization, and after all the heavy lifting by Tomas
>> the patch seems to be in pretty good shape.
>
> I
> On 7 Nov 2021, at 10:26, Etsuro Fujita wrote:
>
> On Sat, Nov 6, 2021 at 6:16 AM Daniel Gustafsson wrote:
>> 2601: Fast COPY FROM command for the foreign tables
>> ===
>> This approach taken in this patch has stabilized and the benchmarks posted
On Sat, Nov 6, 2021 at 6:16 AM Daniel Gustafsson wrote:
> 2601: Fast COPY FROM command for the foreign tables
> ===
> This approach taken in this patch has stabilized and the benchmarks posted are
> very promising. It seems pretty uncontroversial
On 11/5/21 22:15, Daniel Gustafsson wrote:
...
1651: GROUP BY optimization
===
This is IMO a desired optimization, and after all the heavy lifting by Tomas
the patch seems to be in pretty good shape.
I agree it's desirable. To move the patch forward, I need some
> 1741: Index Skip Scan
> =
> An often requested feature which has proven hard to reach consensus on an
> implementation for. The thread(s) have stalled since May,
This statement is not accurate. Peter started a new thread in [1] for this
topic last month and then we had a
Thanks for taking care of this.
> 2433: Erase the distinctClause if the result is unique by definition
>
> (parts of) The approach taken in this patch has been objected against in favor
> of work that Tom has proposed.
Actually
We have amassed quite a lot of patches in the CF app, and while Jaime did a
very good job closing patches in the last CF there is still a lot to go
through. I've attempted a brief per-patch triage here to see where we are with
these. Reading every email in the threads for these patches is a
20 matches
Mail list logo
