On 6/3/21 7:30 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> As mentioned in the previous message, I've reverted most of 39b66a91bd.
> Should this topic be removed from the open-items list now?
>
>
Yep.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.
Tomas Vondra writes:
> As mentioned in the previous message, I've reverted most of 39b66a91bd.
Should this topic be removed from the open-items list now?
regards, tom lane
On Thu, Jun 3, 2021 at 8:02 AM Tomas Vondra
wrote:
>
> OK,
>
> As mentioned in the previous message, I've reverted most of 39b66a91bd.
> It took a bit longer to test, because the revert patch I shared a couple
> days ago was actually incorrect/buggy in one place.
>
> I'm not entirely happy about t
OK,
As mentioned in the previous message, I've reverted most of 39b66a91bd.
It took a bit longer to test, because the revert patch I shared a couple
days ago was actually incorrect/buggy in one place.
I'm not entirely happy about the end result (as it does not really help
with TOAST tables), so h
Hi,
Based on the investigation and (lack of) progress so far, I'll revert
part of the COPY FREEZE improvements shortly. I'll keep the initial
7db0cd2145 changes, tweaking heap_multi_insert, and remove most of
39b66a91bd (except for the heap_xlog_multi_insert bit).
This should address the small 5%
On 5/24/21 8:21 PM, Andres Freund wrote:
> Hi,
>
> On 2021-05-24 12:37:18 +0200, Tomas Vondra wrote:
>> Another option might be changes in the binary layout - 5% change is well
>> within the range that could be attributed to this, but it feels very
>> hand-wavy and more like an excuse than real an
Hi,
On 2021-05-24 12:37:18 +0200, Tomas Vondra wrote:
> Another option might be changes in the binary layout - 5% change is well
> within the range that could be attributed to this, but it feels very
> hand-wavy and more like an excuse than real analysis.
I don't think 5% is likely to be explaine
On 5/24/21 9:53 AM, Masahiko Sawada wrote:
On Sat, May 22, 2021 at 3:10 AM Tomas Vondra
wrote:
On 5/21/21 6:43 PM, Andres Freund wrote:
Hi,
> ...
>
Attached are the flame graphs for all three cases. The change in master is
pretty clearly visible, but I don't see any clear difference
On Sat, May 22, 2021 at 3:10 AM Tomas Vondra
wrote:
>
> On 5/21/21 6:43 PM, Andres Freund wrote:
> > Hi,
> >
> > ...
> >
> >> Attached are the flame graphs for all three cases. The change in master is
> >> pretty clearly visible, but I don't see any clear difference between old
> >> and
> >> pa
On 5/21/21 6:43 PM, Andres Freund wrote:
Hi,
> ...
>
Attached are the flame graphs for all three cases. The change in master is
pretty clearly visible, but I don't see any clear difference between old and
patched code :-(
I'm pretty sure it's the additional WAL records?
Not sure. If I und
Hi,
On 2021-05-21 18:17:01 +0200, Tomas Vondra wrote:
> OK, so here are the flamegraphs, for all three cases - current master,
> 0c7d3bb99 (i.e. before heap_insert changes) and with the pinning patch
> applied. I did this using the same test case as before (50M table), but with
> -fno-omit-frame-p
On Wed, May 19, 2021 at 3:08 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-05-18 11:20:07 +0900, Masahiko Sawada wrote:
> > Yes. It depends on how much the matview refresh gets slower but I
> > think the problem here is that users always are forced to pay the cost
> > for freezing tuple during refre
Hi,
On 2021-05-18 20:43:41 +0200, Tomas Vondra wrote:
> Yeah, emitting WAL is not exactly cheap, although it's just a little bit
> more (0.44%). I haven't looked into the details, but I wonder why it has
> such disproportionate impact (although, the 32 vs. 40 sec may be off).
I couldn't reproduce
Hi,
On 2021-05-18 20:34:08 +0200, Tomas Vondra wrote:
> Yeah, I see your point. I agree it's unfortunate there's no way to disable
> freezing during REFRESH MV. For most users that trade-off is probably fine,
> but for some cases (matviews refreshed often, or cases where it's fine to
> pay more bu
On 5/18/21 8:08 PM, Andres Freund wrote:
Hi,
On 2021-05-18 11:20:07 +0900, Masahiko Sawada wrote:
Yes. It depends on how much the matview refresh gets slower but I
think the problem here is that users always are forced to pay the cost
for freezing tuple during refreshing the matview. There i
On 5/18/21 4:20 AM, Masahiko Sawada wrote:
> ...
I think the changes for heap_multi_insert() are fine so we can revert
only heap_insert() part if we revert something from the v14 tree,
although we will end up not inserting frozen tuples into toast tables.
I'd be somewhat unhappy about revert
Hi,
On 2021-05-18 11:20:07 +0900, Masahiko Sawada wrote:
> Yes. It depends on how much the matview refresh gets slower but I
> think the problem here is that users always are forced to pay the cost
> for freezing tuple during refreshing the matview. There is no way to
> disable it unlike FREEZE op
On Wed, May 12, 2021 at 2:32 AM Tomas Vondra
wrote:
>
>
>
> On 5/11/21 5:56 PM, Masahiko Sawada wrote:
> > On Tue, May 11, 2021 at 11:07 PM Tomas Vondra
> > wrote:
> >>
> >> On 5/11/21 11:04 AM, Masahiko Sawada wrote:
> >>> On Tue, May 11, 2021 at 4:37 PM Michael Paquier
> >>> wrote:
>
> >
On Tue, May 11, 2021 at 11:46 AM Andrew Dunstan wrote:
> > Yes, reverting has its place. Moreover, threats of reversion have their
> > place. People should definitely be working towards finding solutions to
> > the problems in their commits lest they be reverted. However, freezing
> > *people*
Hi,
On 2021-05-13 11:12:43 +0900, Michael Paquier wrote:
> If that's the consensus reached, that's fine by me as long as we don't
> keep a 25% performance regression. Now, looking at the patch
> proposed, I have to admit that this looks like some redesign of an
> existing feature, so that stresse
On Tue, May 11, 2021 at 02:46:35PM -0400, Andrew Dunstan wrote:
> On 5/11/21 2:23 PM, Alvaro Herrera wrote:
>> Yes, reverting has its place. Moreover, threats of reversion have their
>> place. People should definitely be working towards finding solutions to
>> the problems in their commits lest t
On 5/11/21 2:23 PM, Alvaro Herrera wrote:
> On 2021-May-11, Michael Paquier wrote:
>
>> Hmm. Is that really something we should do after feature freeze? A
>> 25% degradation for matview refresh may be a problem for a lot of
>> users and could be an upgrade stopper. Another thing we could do is
On 2021-May-11, Michael Paquier wrote:
> Hmm. Is that really something we should do after feature freeze? A
> 25% degradation for matview refresh may be a problem for a lot of
> users and could be an upgrade stopper. Another thing we could do is
> also to revert 7db0cd2 and 39b66a9 from the v14
On 5/11/21 7:25 PM, Andres Freund wrote:
Hi,
On 2021-05-11 16:07:44 +0200, Tomas Vondra wrote:
On 5/11/21 11:04 AM, Masahiko Sawada wrote:
I think the changes for heap_multi_insert() are fine so we can revert
only heap_insert() part if we revert something from the v14 tree,
although we will
On 5/11/21 5:56 PM, Masahiko Sawada wrote:
On Tue, May 11, 2021 at 11:07 PM Tomas Vondra
wrote:
On 5/11/21 11:04 AM, Masahiko Sawada wrote:
On Tue, May 11, 2021 at 4:37 PM Michael Paquier wrote:
On Wed, May 05, 2021 at 03:04:53PM +0200, Tomas Vondra wrote:
Thanks, that looks promising.
Hi,
On 2021-05-11 16:07:44 +0200, Tomas Vondra wrote:
> On 5/11/21 11:04 AM, Masahiko Sawada wrote:
> > I think the changes for heap_multi_insert() are fine so we can revert
> > only heap_insert() part if we revert something from the v14 tree,
> > although we will end up not inserting frozen tuple
On Tue, May 11, 2021 at 11:07 PM Tomas Vondra
wrote:
>
> On 5/11/21 11:04 AM, Masahiko Sawada wrote:
> > On Tue, May 11, 2021 at 4:37 PM Michael Paquier wrote:
> >>
> >> On Wed, May 05, 2021 at 03:04:53PM +0200, Tomas Vondra wrote:
> >>> Thanks, that looks promising. I repeated the tests I did on
On 5/11/21 11:04 AM, Masahiko Sawada wrote:
On Tue, May 11, 2021 at 4:37 PM Michael Paquier wrote:
On Wed, May 05, 2021 at 03:04:53PM +0200, Tomas Vondra wrote:
Thanks, that looks promising. I repeated the tests I did on 26/4, and the
results look like this:
old (0c7d3bb99): 497ms
master:
On 5/11/21 12:58 PM, Bharath Rupireddy wrote:
On Tue, May 11, 2021 at 2:34 PM Masahiko Sawada wrote:
I think the approach proposed by Andres eliminates the extra vmbuffer
reads as much as possible. But even with the patch, there still is 5%
degradation (and there is no way to disable inserti
On Tue, May 11, 2021 at 2:34 PM Masahiko Sawada wrote:
> I think the approach proposed by Andres eliminates the extra vmbuffer
> reads as much as possible. But even with the patch, there still is 5%
> degradation (and there is no way to disable inserting frozen tuples at
> matview refresh). Which
On Tue, May 11, 2021 at 4:37 PM Michael Paquier wrote:
>
> On Wed, May 05, 2021 at 03:04:53PM +0200, Tomas Vondra wrote:
> > Thanks, that looks promising. I repeated the tests I did on 26/4, and the
> > results look like this:
> >
> > old (0c7d3bb99): 497ms
> > master: 621ms
> > patched:
On Wed, May 05, 2021 at 03:04:53PM +0200, Tomas Vondra wrote:
> Thanks, that looks promising. I repeated the tests I did on 26/4, and the
> results look like this:
>
> old (0c7d3bb99): 497ms
> master: 621ms
> patched: 531ms
>
> So yeah, that's a bit improvement - it does not remo
On 4/27/21 8:22 PM, Andres Freund wrote:
Hi,
On 2021-04-28 00:44:47 +0900, Masahiko Sawada wrote:
On Wed, Apr 28, 2021 at 12:26 AM Masahiko Sawada wrote:
What Andres is suggesting (I think) is to modify ExecInsert() to pass a
valid bistate to table_tuple_insert, instead of just NULL, and s
Hi,
On 2021-04-28 00:44:47 +0900, Masahiko Sawada wrote:
> On Wed, Apr 28, 2021 at 12:26 AM Masahiko Sawada
> wrote:
> > > What Andres is suggesting (I think) is to modify ExecInsert() to pass a
> > > valid bistate to table_tuple_insert, instead of just NULL, and store the
> > > vmbuffer in it.
On 4/27/21 5:44 PM, Masahiko Sawada wrote:
On Wed, Apr 28, 2021 at 12:26 AM Masahiko Sawada wrote:
On Tue, Apr 27, 2021 at 10:43 PM Tomas Vondra
wrote:
On 4/27/21 7:34 AM, Masahiko Sawada wrote:
On Tue, Apr 27, 2021 at 8:07 AM Andres Freund wrote:
Hi,
On 2021-04-26 23:59:17 +0200, To
On Wed, Apr 28, 2021 at 12:26 AM Masahiko Sawada wrote:
>
> On Tue, Apr 27, 2021 at 10:43 PM Tomas Vondra
> wrote:
> >
> >
> >
> > On 4/27/21 7:34 AM, Masahiko Sawada wrote:
> > > On Tue, Apr 27, 2021 at 8:07 AM Andres Freund wrote:
> > >>
> > >> Hi,
> > >>
> > >> On 2021-04-26 23:59:17 +0200, T
On Tue, Apr 27, 2021 at 10:43 PM Tomas Vondra
wrote:
>
>
>
> On 4/27/21 7:34 AM, Masahiko Sawada wrote:
> > On Tue, Apr 27, 2021 at 8:07 AM Andres Freund wrote:
> >>
> >> Hi,
> >>
> >> On 2021-04-26 23:59:17 +0200, Tomas Vondra wrote:
> >>> On 4/26/21 9:27 PM, Andres Freund wrote:
> On 2021-
On Tue, Apr 27, 2021 at 03:43:07PM +0200, Tomas Vondra wrote:
> On 4/27/21 7:34 AM, Masahiko Sawada wrote:
> > On Tue, Apr 27, 2021 at 8:07 AM Andres Freund wrote:
> > > On 2021-04-26 23:59:17 +0200, Tomas Vondra wrote:
> > > > On 4/26/21 9:27 PM, Andres Freund wrote:
> > > > > On 2021-04-26 15:31
On Tue, Apr 27, 2021 at 7:13 PM Tomas Vondra
wrote:
> What Andres is suggesting (I think) is to modify ExecInsert() to pass a
> valid bistate to table_tuple_insert, instead of just NULL, and store the
> vmbuffer in it. Not sure how to identify when inserting more than just a
> single row, though .
On 4/27/21 7:34 AM, Masahiko Sawada wrote:
On Tue, Apr 27, 2021 at 8:07 AM Andres Freund wrote:
Hi,
On 2021-04-26 23:59:17 +0200, Tomas Vondra wrote:
On 4/26/21 9:27 PM, Andres Freund wrote:
On 2021-04-26 15:31:02 +0200, Tomas Vondra wrote:
I'm not sure what to do about this :-( I don't
On Tue, Apr 27, 2021 at 8:07 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-04-26 23:59:17 +0200, Tomas Vondra wrote:
> > On 4/26/21 9:27 PM, Andres Freund wrote:
> > > On 2021-04-26 15:31:02 +0200, Tomas Vondra wrote:
> > > > I'm not sure what to do about this :-( I don't have any ideas about how
>
On Mon, Apr 26, 2021 at 10:31 PM Tomas Vondra
wrote:
>
> Hi,
>
> I took a look at this today, as I committed 39b66a91b back in January. I
> can reproduce the issue, with just 1M rows the before/after timings are
> roughly 480ms and 620ms on my hardware.
>
> Unfortunately, the v3 patch does not rea
Hi,
On 2021-04-26 23:59:17 +0200, Tomas Vondra wrote:
> On 4/26/21 9:27 PM, Andres Freund wrote:
> > On 2021-04-26 15:31:02 +0200, Tomas Vondra wrote:
> > > I'm not sure what to do about this :-( I don't have any ideas about how to
> > > eliminate this overhead, so the only option I see is reverti
On 4/26/21 9:27 PM, Andres Freund wrote:
Hi,
On 2021-04-26 15:31:02 +0200, Tomas Vondra wrote:
I'm not sure what to do about this :-( I don't have any ideas about how to
eliminate this overhead, so the only option I see is reverting the changes
in heap_insert. Unfortunately, that'd mean inse
Hi,
On 2021-04-26 15:31:02 +0200, Tomas Vondra wrote:
> I'm not sure what to do about this :-( I don't have any ideas about how to
> eliminate this overhead, so the only option I see is reverting the changes
> in heap_insert. Unfortunately, that'd mean inserts into TOAST tables won't
> be frozen .
Hi,
I took a look at this today, as I committed 39b66a91b back in January. I
can reproduce the issue, with just 1M rows the before/after timings are
roughly 480ms and 620ms on my hardware.
Unfortunately, the v3 patch does not really fix the issue for me. The
timing with it applied is ~610ms
On Tue, Apr 20, 2021 at 11:20 AM Masahiko Sawada wrote:
>
> On Tue, Apr 20, 2021 at 11:04 AM Bharath Rupireddy
> wrote:
> >
> > On Mon, Apr 19, 2021 at 7:21 PM Masahiko Sawada
> > wrote:
> > > I’ve updated the patch including the above comment.
> >
> > Thanks for the patch.
> >
> > I was trying
On Tue, Apr 20, 2021 at 11:04 AM Bharath Rupireddy
wrote:
>
> On Mon, Apr 19, 2021 at 7:21 PM Masahiko Sawada wrote:
> > I’ve updated the patch including the above comment.
>
> Thanks for the patch.
>
> I was trying to understand below statements:
> + * we check without a buffer l
On Mon, Apr 19, 2021 at 7:21 PM Masahiko Sawada wrote:
> I’ve updated the patch including the above comment.
Thanks for the patch.
I was trying to understand below statements:
+ * we check without a buffer lock if the page is empty but the
+ * caller doesn't need
On Mon, Apr 19, 2021 at 8:04 PM Bharath Rupireddy
wrote:
>
> On Mon, Apr 19, 2021 at 1:57 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 19, 2021 at 5:04 PM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Mon, 19 Apr 2021 13:32:31 +0900, Masahiko Sawada
> > > wrote in
> > > > On Fri, Apr 16, 2021 a
On Mon, Apr 19, 2021 at 1:57 PM Masahiko Sawada wrote:
>
> On Mon, Apr 19, 2021 at 5:04 PM Kyotaro Horiguchi
> wrote:
> >
> > At Mon, 19 Apr 2021 13:32:31 +0900, Masahiko Sawada
> > wrote in
> > > On Fri, Apr 16, 2021 at 12:16 PM Kyotaro Horiguchi
> > > wrote:
> > > > AFAICS the page is always
On Mon, Apr 19, 2021 at 5:04 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 19 Apr 2021 13:32:31 +0900, Masahiko Sawada
> wrote in
> > On Fri, Apr 16, 2021 at 12:16 PM Kyotaro Horiguchi
> > wrote:
> > > AFAICS the page is always empty when RelationGetBufferForTuple
> > > returned a valid vmbuffer. So
At Mon, 19 Apr 2021 13:32:31 +0900, Masahiko Sawada
wrote in
> On Fri, Apr 16, 2021 at 12:16 PM Kyotaro Horiguchi
> wrote:
> > AFAICS the page is always empty when RelationGetBufferForTuple
> > returned a valid vmbuffer. So the "if" should be an "assert" instead.
>
> There is a chance that Re
On Fri, Apr 16, 2021 at 12:16 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 12 Apr 2021 15:20:41 +0900, Masahiko Sawada
> wrote in
> > .
> >
> > On Thu, Mar 11, 2021 at 5:44 PM Masahiko Sawada
> > wrote:
> > >
> > > Hi,
> > >
> > > While discussing freezing tuples during CTAS[1], we found that
> > >
At Mon, 12 Apr 2021 15:20:41 +0900, Masahiko Sawada
wrote in
> .
>
> On Thu, Mar 11, 2021 at 5:44 PM Masahiko Sawada wrote:
> >
> > Hi,
> >
> > While discussing freezing tuples during CTAS[1], we found that
> > heap_insert() with HEAP_INSERT_FROZEN brings performance degradation.
> > For insta
.
On Thu, Mar 11, 2021 at 5:44 PM Masahiko Sawada wrote:
>
> Hi,
>
> While discussing freezing tuples during CTAS[1], we found that
> heap_insert() with HEAP_INSERT_FROZEN brings performance degradation.
> For instance, with Paul's patch that sets HEAP_INSERT_FROZEN to CTAS,
> it took 12 sec wher
On Fri, Mar 12, 2021 at 3:13 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-03-11 17:44:37 +0900, Masahiko Sawada wrote:
> > The execution time of REFRESH MATERIALIZED VIEW are:
> >
> > w/ HEAP_INSERT_FROZEN flag : 42 sec
> > w/o HEAP_INSERT_FROZEN flag : 33 sec
> >
> > After investigation, I found t
Hi,
On 2021-03-11 17:44:37 +0900, Masahiko Sawada wrote:
> The execution time of REFRESH MATERIALIZED VIEW are:
>
> w/ HEAP_INSERT_FROZEN flag : 42 sec
> w/o HEAP_INSERT_FROZEN flag : 33 sec
>
> After investigation, I found that such performance degradation happens
> on only HEAD code. It seems
58 matches
Mail list logo
