On Thu, Aug 1, 2019 at 8:34 AM Brandur Leach wrote:
> Thanks Peter. V6 is pretty uncontroversial by me — the new
> conditional ladder broken cleanly into cases of (1) all
> subnet, (2) network/subnet mix, and (3) all network is a
> little more verbose, but all in all makes things easier to
>
Thanks Peter. V6 is pretty uncontroversial by me — the new
conditional ladder broken cleanly into cases of (1) all
subnet, (2) network/subnet mix, and (3) all network is a
little more verbose, but all in all makes things easier to
reason about.
> Do you have any final input on the testing,
On Fri, Jul 26, 2019 at 7:25 PM Peter Geoghegan wrote:
> I guess that the idea here was to prevent masking on ipv6 addresses,
> though not on ipv4 addresses. Obviously we're only dealing with a
> prefix with ipv6 addresses, whereas we usually have the whole raw
> ipaddr with ipv4. Not sure if I'm
And a slightly amended version of the last patch with a bug
fixed where IPv4 abbreviated keys were were not being
initialized correctly on big-endian machines.
v5-0001-SortSupport-for-inet-cidr-types.patch
Description: Binary data
Thanks the follow ups on this one Edmund/Peter!
I've attached a new V4 variant of the patch based on
Peter's V3, mostly containing comment amendments and a few
other minor stylistic fixes.
> An interesting thing about sorting IPv4 inets on 64-bit machines is that
when the inets are the same, the
On Fri, Jul 26, 2019 at 6:58 PM Peter Geoghegan wrote:
> I found this part of your approach confusing:
>
> > + /*
> > +* Number of bits in subnet. e.g. An IPv4 that's /24 is 32 - 24 = 8.
> > +*
> > +* However, only some of the bits may have made it into the fixed sized
> > +*
On Fri, Feb 8, 2019 at 10:20 AM Brandur Leach wrote:
> Attached a V2 patch: identical to V1 except rebased and
> with a new OID selected.
Attached is a revised version that I came up with, based on your v2.
I found this part of your approach confusing:
> + /*
> +* Number of bits in
On Fri, Feb 8, 2019 at 11:13 PM Edmund Horner wrote:
> I have some comments on the comments:
Seems reasonable to me.
Where are we on this? I'd like to get the patch committed soon.
--
Peter Geoghegan
On 2/16/19 4:13 AM, Andres Freund wrote:
On 2019-02-09 20:12:53 +1300, Edmund Horner wrote:
I had a look at this. Your V2 patch applies cleanly, and the code was
straightforward and well commented. I appreciate the big comment at the
top of network_abbrev_convert explaining how you encode
Hi Brandur,
On 2019-02-09 20:12:53 +1300, Edmund Horner wrote:
> I had a look at this. Your V2 patch applies cleanly, and the code was
> straightforward and well commented. I appreciate the big comment at the
> top of network_abbrev_convert explaining how you encode the data.
I've marked the
On Sat, 9 Feb 2019 at 04:48, Brandur Leach wrote:
> I've attached a patch that implements SortSupport for the
> inet/cidr types. It has the effect of typically reducing
> the time taken to sort these types by ~50-60% (as measured
> by `SELECT COUNT(DISTINCT ...)` which will carry over to
> common
Attached a V2 patch: identical to V1 except rebased and
with a new OID selected.
SortSupport-for-inet-cidr-types-v2.patch
Description: Binary data
Hi list,
I've attached a patch that implements SortSupport for the
inet/cidr types. It has the effect of typically reducing
the time taken to sort these types by ~50-60% (as measured
by `SELECT COUNT(DISTINCT ...)` which will carry over to
common operations like index creation, `ORDER BY`, and
13 matches
Mail list logo
