On Wed, 8 Apr 2020 at 15:06, John Naylor wrote:
> Looks good to me, marked RFC.
Thanks a lot for reviewing those changes. I've now pushed all 3 of the patches.
David
On Wed, Apr 8, 2020 at 9:04 AM David Rowley wrote:
> [v8]
Looks good to me, marked RFC.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, 8 Apr 2020 at 01:16, John Naylor wrote:
>
> On Tue, Apr 7, 2020 at 8:26 PM David Rowley wrote:
> >
> > Hi John,
> >
> > Thanks for having a look at this.
> >
> > On Wed, 8 Apr 2020 at 00:16, John Naylor
> > wrote:
> > > Overall looks good to me. Just a couple things I see:
> > >
> > >
On Tue, Apr 7, 2020 at 8:26 PM David Rowley wrote:
>
> Hi John,
>
> Thanks for having a look at this.
>
> On Wed, 8 Apr 2020 at 00:16, John Naylor wrote:
> > Overall looks good to me. Just a couple things I see:
> >
> > It seems _hash_log2 is still in the tree, but has no callers?
>
> Yeah, I
Hi John,
Thanks for having a look at this.
On Wed, 8 Apr 2020 at 00:16, John Naylor wrote:
> Overall looks good to me. Just a couple things I see:
>
> It seems _hash_log2 is still in the tree, but has no callers?
Yeah, I left it in there since it was an external function. Perhaps
we could rip
On Tue, Apr 7, 2020 at 7:41 PM David Rowley wrote:
> I've attached an updated patch. It includes the modifications
> mentioned above to pre-check for a power of 2 number with the bit
> masking hack mentioned above. I also renamed the functions to be more
> aligned to the other functions in
On Thu, 12 Mar 2020 at 22:59, John Naylor wrote:
>
> On Thu, Mar 12, 2020 at 7:42 AM David Rowley wrote:
> >
> > I don't think Jesse's proposed solution is that great due to the
> > additional function call overhead for pg_count_leading_zeros_32(). The
> > (num & (num - 1)) == 0 I imagine will
On Thu, Mar 12, 2020 at 7:42 AM David Rowley wrote:
>
> I don't think Jesse's proposed solution is that great due to the
> additional function call overhead for pg_count_leading_zeros_32(). The
> (num & (num - 1)) == 0 I imagine will perform better, but I didn't
> test it.
Right, I believe we've
On Sat, 29 Feb 2020 at 04:13, David Fetter wrote:
>
> On Thu, Feb 27, 2020 at 02:41:49PM +0800, John Naylor wrote:
> > In 0002, the pg_bitutils functions have a test (input > 0), and the
> > new callers ceil_log2_* and next_power_of_2_* have asserts. That seems
> > backward to me.
>
> To me, too,
Hi David,
On Sun, Mar 8, 2020 at 11:34 AM David Fetter wrote:
>
> On Mon, Mar 02, 2020 at 12:45:21PM -0800, Jesse Zhang wrote:
> > Hi David,
>
> Per discussion on IRC with Andrew (RhodiumToad) Gierth:
>
> The runtime detection means there's always an indirect call overhead
> and no way to inline.
Hi John,
Oops this email has been sitting in my outbox for 3 days...
On Wed, Mar 4, 2020 at 1:46 AM John Naylor wrote:
> On Tue, Mar 3, 2020 at 4:46 AM Jesse Zhang wrote:
> > I've quickly put together a PoC patch on top of yours, which
> > re-implements ceil_log2 using LZCNT coupled with a
On Mon, Mar 02, 2020 at 12:45:21PM -0800, Jesse Zhang wrote:
> Hi David,
>
> On Wed, Feb 26, 2020 at 9:56 PM David Fetter wrote:
> >
> > On Wed, Feb 26, 2020 at 09:12:24AM +0100, David Fetter wrote:
> > > On Fri, Jan 31, 2020 at 04:59:18PM +0100, David Fetter wrote:
> > > > On Wed, Jan 15, 2020
On Tue, Mar 3, 2020 at 4:46 AM Jesse Zhang wrote:
> The math in the new (from v4 to v6) patch is wrong: it yields
> ceil_log2(1) = 1 or next_power_of_2(1) = 2.
I think you're right.
> I can see that you lifted
> the restriction of "num greater than one" for ceil_log2() in this patch
> set, but
On Thu, Feb 27, 2020 at 1:56 PM David Fetter wrote:
>
> [v6 patch set]
Here I'm only looking at 0001. It needs rebasing, but it's trivial to
see what it does. I noticed in some places, you've replaced "long"
with uint64, but many are int64. I started making a list, but it got
too long, and I had
Hi David,
On Wed, Feb 26, 2020 at 9:56 PM David Fetter wrote:
>
> On Wed, Feb 26, 2020 at 09:12:24AM +0100, David Fetter wrote:
> > On Fri, Jan 31, 2020 at 04:59:18PM +0100, David Fetter wrote:
> > > On Wed, Jan 15, 2020 at 03:45:12PM -0800, Jesse Zhang wrote:
> > > > On Tue, Jan 14, 2020 at
On Thu, Feb 27, 2020 at 02:41:49PM +0800, John Naylor wrote:
> On Thu, Feb 27, 2020 at 1:56 PM David Fetter wrote:
> > [v6 set]
>
> Hi David,
>
> In 0002, the pg_bitutils functions have a test (input > 0), and the
> new callers ceil_log2_* and next_power_of_2_* have asserts. That seems
>
On Thu, Feb 27, 2020 at 1:56 PM David Fetter wrote:
> [v6 set]
Hi David,
In 0002, the pg_bitutils functions have a test (input > 0), and the
new callers ceil_log2_* and next_power_of_2_* have asserts. That seems
backward to me. I imagine some callers of bitutils will already know
the value > 0,
On Wed, Feb 26, 2020 at 09:12:24AM +0100, David Fetter wrote:
> On Fri, Jan 31, 2020 at 04:59:18PM +0100, David Fetter wrote:
> > On Wed, Jan 15, 2020 at 03:45:12PM -0800, Jesse Zhang wrote:
> > > On Tue, Jan 14, 2020 at 2:09 PM David Fetter wrote:
> > > > > The changes in hash AM and SIMPLEHASH
On Fri, Jan 31, 2020 at 04:59:18PM +0100, David Fetter wrote:
> On Wed, Jan 15, 2020 at 03:45:12PM -0800, Jesse Zhang wrote:
> > On Tue, Jan 14, 2020 at 2:09 PM David Fetter wrote:
> > > > The changes in hash AM and SIMPLEHASH do look like a net positive
> > > > improvement. My biggest cringe
On Wed, Jan 15, 2020 at 03:45:12PM -0800, Jesse Zhang wrote:
> On Tue, Jan 14, 2020 at 2:09 PM David Fetter wrote:
> > > The changes in hash AM and SIMPLEHASH do look like a net positive
> > > improvement. My biggest cringe might be in pg_bitutils:
> > >
> > > 1. Is ceil_log2_64 dead code?
> >
>
calls, and could get out of date easily.
Removed.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From e7716fad797362308a19d4a78304e0e167d37f48 Mon Sep 17 00:00:00 2001
From: David
On Wed, Jan 15, 2020 at 6:09 AM David Fetter wrote:
> [v2 patch]
Hi David,
I have a stylistic comment on this snippet:
- for (i = _hash_log2(metap->hashm_bsize); i > 0; --i)
- {
- if ((1 << i) <= metap->hashm_bsize)
- break;
- }
+ i = pg_leftmost_one_pos32(metap->hashm_bsize);
Assert(i >
On Tue, Jan 14, 2020 at 2:09 PM David Fetter wrote:
> > The changes in hash AM and SIMPLEHASH do look like a net positive
> > improvement. My biggest cringe might be in pg_bitutils:
> >
> > 1. Is ceil_log2_64 dead code?
>
> Let's call it nascent code. I suspect there are places it could go, if
>
more attractive. Is there some way to tilt the tools so
that this happens? What should I be reading up on?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From b542c9efb4f4ec3999a9e
Hi David,
On Tue, Jan 14, 2020 at 9:36 AM David Fetter wrote:
>
> Folks,
>
> The recent patch for distinct windowing aggregates contained a partial
> fix of the FIXME that didn't seem entirely right, so I extracted that
> part, changed it to use compiler intrinsics, and submit it here.
The
to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From 2d0022be8cb117da0eadc76900d6558853e4 Mon Sep 17 00:00:00 2001
From: David Fetter
Date: Tue, 14 Jan 2020 09:32:15 -0800
Subject: [PATCH v1] Use compiler intrinsics for bit ops in hash
To: hackers
MIME-Vers
26 matches
Mail list logo
