On Mon, Nov 2, 2020 at 1:04 PM Peter Geoghegan wrote:
> if Andres cannot spend any time on this in the foreseeable future then
> I'll withdraw the patch. I intend to formally withdraw the patch on
> November 9th, provided no new information comes to light.
I have now formally withdrawn the patch
On Mon, Nov 2, 2020 at 9:46 AM Anastasia Lubennikova
wrote:
> This thread was inactive for a while. The latest review suggests that it is
> Ready For Committer.
> I also took a quick look at the patch and agree that it looks sensible. Maybe
> add a comment before the _bt_compare_inl() to explain
On Thu, May 28, 2020 at 12:35 PM Mark Dilger
wrote:
> Reading this thread, I think the lack of a performance impact on laptop
> hardware was expected, but perhaps confirmation that it does not make things
> worse is useful?
>
> Since this patch doesn't seem to do any harm, I would mark it as "re
Status update for a commitfest entry.
This thread was inactive for a while. The latest review suggests that it is
Ready For Committer.
I also took a quick look at the patch and agree that it looks sensible. Maybe
add a comment before the _bt_compare_inl() to explain the need for this code
chang
> On Mar 2, 2020, at 5:29 PM, Peter Geoghegan wrote:
>
> On Sun, Mar 1, 2020 at 12:15 PM Floris Van Nee
> wrote:
>> Minor conflict with that patch indeed. Attached is rebased version. I'm
>> running some tests now - will post the results here when finished.
>
> Thanks.
>
> We're going to
> Attached is v5, which inlines in a targeted fashion, pretty much in the same
> way as the earliest version. This is the same as v4 in every other way.
> Perhaps you can test this.
>
Thank you for the new patch. With the new one I am indeed able to reproduce a
performance increase. It is very d
On Sun, Mar 1, 2020 at 12:15 PM Floris Van Nee wrote:
> Minor conflict with that patch indeed. Attached is rebased version. I'm
> running some tests now - will post the results here when finished.
Thanks.
We're going to have to go back to my original approach to inlining. At
least, it seemed to
> The cfbot thinks it doesn't even apply anymore --- conflict with the dedup
> patch, no doubt?
Minor conflict with that patch indeed. Attached is rebased version. I'm running
some tests now - will post the results here when finished.
-Floris
v4-0001-Avoid-pipeline-stall-in-_bt_compare.patch
Peter Geoghegan writes:
> Attached is v3, which no longer includes the third patch/optimization.
> It also inlines (in the second patch) by marking the _bt_compare
> definition as inline, while not changing anything in nbtree.h. I
> believe that this is portable C99 -- let's see what CF Tester thi
On Wed, Feb 19, 2020 at 2:45 PM Tom Lane wrote:
> The buildfarm would only tell you if it compiles, not whether the
> performance results are what you hoped for.
Right. Plus I think that more granular control might make more sense
in this particular instance anyway.
--
Peter Geoghegan
Andres Freund writes:
> On 2020-02-19 15:55:38 -0500, Tom Lane wrote:
>> Boy, I'd be pretty darn hesitant to go there, even with our new
>> expectation of C99 compilers. What we found out when we last experimented
>> with non-static inlines was that the semantics were not very portable nor
>> des
Hi,
On 2020-02-19 15:55:38 -0500, Tom Lane wrote:
> Peter Geoghegan writes:
> > It also inlines (in the second patch) by marking the _bt_compare
> > definition as inline, while not changing anything in nbtree.h. I
> > believe that this is portable C99 -- let's see what CF Tester thinks
> > of it.
Peter Geoghegan writes:
> On Wed, Feb 19, 2020 at 12:55 PM Tom Lane wrote:
>> Boy, I'd be pretty darn hesitant to go there, even with our new
>> expectation of C99 compilers. What we found out when we last experimented
>> with non-static inlines was that the semantics were not very portable nor
On Wed, Feb 19, 2020 at 12:55 PM Tom Lane wrote:
> Boy, I'd be pretty darn hesitant to go there, even with our new
> expectation of C99 compilers. What we found out when we last experimented
> with non-static inlines was that the semantics were not very portable nor
> desirable. I've forgotten t
Peter Geoghegan writes:
> It also inlines (in the second patch) by marking the _bt_compare
> definition as inline, while not changing anything in nbtree.h. I
> believe that this is portable C99 -- let's see what CF Tester thinks
> of it.
Boy, I'd be pretty darn hesitant to go there, even with our
On Mon, Feb 10, 2020 at 1:05 AM Floris Van Nee wrote:
> I ran all the tests on two different machines, several times for 1 hour each
> time. I'm still having a hard time getting reliable results for the 30
> clients case though. I'm pretty certain the patches bring a performance
> benefit, but
On Tue, Feb 18, 2020 at 4:45 PM Thomas Munro wrote:
> Yeah, for CF entries with multiple threads, it currently looks at
> whichever thread has the most recent email on it, and then it finds
> the most recent patch set on that thread. Perhaps it should look at
> all the registered threads and find
On Wed, Feb 19, 2020 at 1:35 PM Peter Geoghegan wrote:
> On Tue, Feb 18, 2020 at 12:55 PM Thomas Munro wrote:
> > The cfbot seems to be showing "pg_regress: initdb failed" on Ubuntu,
> > with an assertion failure like this:
> >
> > #2 0x008e594f in ExceptionalCondition
> > (conditionName=
On Tue, Feb 18, 2020 at 12:55 PM Thomas Munro wrote:
> The cfbot seems to be showing "pg_regress: initdb failed" on Ubuntu,
> with an assertion failure like this:
>
> #2 0x008e594f in ExceptionalCondition
> (conditionName=conditionName@entry=0x949098 "BTreeTupleGetNAtts(itup,
> rel) >= key
On Mon, Feb 10, 2020 at 10:05 PM Floris Van Nee
wrote:
> > The interesting thing now is the role of the "negative infinity test"
> > patch (the 0003-* patch) in all of this. I suspect that it may not be
> > helping us
> > much here. I wonder, could you test the following configurations to settle
>
> The interesting thing now is the role of the "negative infinity test"
> patch (the 0003-* patch) in all of this. I suspect that it may not be helping
> us
> much here. I wonder, could you test the following configurations to settle
> this question?
>
> * with 30 clients (i.e. repeat the tes
On Thu, Jan 30, 2020 at 1:19 AM Floris Van Nee wrote:
> I'd say applying just v2-0001 is actually slightly hurtful for single-core
> performance. Applying all of them gives a good improvement though. It looks
> like the performance improvement is also more noticeable at higher core
> counts now
>
> Can you test this version, Floris? The second two patches are probably not
> helping here, so it would be useful if you could just test 0001-*, and then
> test
> all three together. I can toss the latter two patches if there is no
> additional
> speedup.
>
Here's the results for runs with
On Tue, Jan 28, 2020 at 1:34 PM Floris Van Nee wrote:
> With Andres' instructions I ran a couple of tests. With your patches I can
> reproduce a speedup of ~3% on single core tests reliably on a dual-socket
> 36-core machine for the pgbench select-only test case.
Thanks for testing!
Attached i
>
> I could do some tests with the patch on some larger machines. What exact
> tests do you propose? Are there some specific postgresql.conf settings and
> pgbench initialization you recommend for this? And was the test above just
> running 'pgbench -S' select-only with specific -T, -j and -c par
On Mon, Jan 27, 2020 at 9:14 AM Andres Freund wrote:
> > The main idea here is to make _bt_compare() delay
> > calling BTreeTupleGetNAtts() until the point after the first attribute
> > turns out to be equal to the _bt_compare() caller's insertion scankey.
> > Many or most calls to _bt_compare() w
Hi,
On 2020-01-26 14:49:06 -0800, Peter Geoghegan wrote:
> Andres and I discussed bottlenecks in the nbtree code during the
> recent PgDay SF community event. Andres observed that the call to
> BTreeTupleGetNAtts() in _bt_compare() can become somewhat of a
> bottleneck. I came up with the very sim
Hi,
On 2020-01-27 15:42:06 +, Floris Van Nee wrote:
>
> > He reported that the problem went away with the patches applied. The
> > following pgbench SELECT-only result was sent to me privately:
> >
> > before:
> > single: tps = 30300.202363 (excluding connections establishing)
> > al
> He reported that the problem went away with the patches applied. The
> following pgbench SELECT-only result was sent to me privately:
>
> before:
> single: tps = 30300.202363 (excluding connections establishing)
> all cores: tps = 1026853.447047 (excluding connections establishing)
Andres and I discussed bottlenecks in the nbtree code during the
recent PgDay SF community event. Andres observed that the call to
BTreeTupleGetNAtts() in _bt_compare() can become somewhat of a
bottleneck. I came up with the very simple attached POC-quality
patches, which Andres tested and profiled
30 matches
Mail list logo
