On Fri, Mar 31, 2017 at 3:03 PM, Brandur Leach wrote:
> Thank you Peter for the assist here and great sleuthing in
> the disassembly, and thanks Teodor for committing!
>
> Neha pointed out (thanks as well) a couple typos upthread
> that I hadn't gotten around to fixing. I've attached a new
> three
Hello,
Thank you Peter for the assist here and great sleuthing in
the disassembly, and thanks Teodor for committing!
Neha pointed out (thanks as well) a couple typos upthread
that I hadn't gotten around to fixing. I've attached a new
three line patch to sort those out.
Brandur
On Wed, Mar 29,
Thank you, pushed
Excellent! I've attached a new (and hopefully final)
version of the patch.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-
On Sun, Mar 19, 2017 at 8:40 AM, Greg Stark wrote:
>> Out of idle curiosity, I decided to generate disassembly of both
>> macaddr_cmp_internal(), and the patch's abbreviated comparator. The
>> former consists of 49 x86-64 instructions at -02 on my machine,
>> totaling 135 bytes of object code. The
On 18 March 2017 at 22:22, Peter Geoghegan wrote:
>
> Out of idle curiosity, I decided to generate disassembly of both
> macaddr_cmp_internal(), and the patch's abbreviated comparator. The
> former consists of 49 x86-64 instructions at -02 on my machine,
> totaling 135 bytes of object code. The la
On Sat, Mar 18, 2017 at 2:54 PM, Peter Geoghegan wrote:
> This seems fine to me, especially
> because it lets us compare macaddr using simple 3-way unsigned int
> comparisons, which isn't otherwise the case.
Out of idle curiosity, I decided to generate disassembly of both
macaddr_cmp_internal(),
On Tue, Mar 14, 2017 at 3:25 AM, Heikki Linnakangas wrote:
> Looks straightforward at a quick read-through. I have just a couple of
> questions. How much of the performance gain comes from avoiding the
> FunctionCallInvoke overhead, by simply having SortSupport with a comparison
> function, and ho
Looks straightforward at a quick read-through. I have just a couple of
questions. How much of the performance gain comes from avoiding the
FunctionCallInvoke overhead, by simply having SortSupport with a
comparison function, and how much comes from the "abbreviation"?
Also, is it worth the cyc
Hi Brandur,
Couple of typo corrections required in patch:
s/converstion/conversion
s/go the heap/go to the heap
The performance results you shared are for he Index Creation operation.
Are there similar results for the sorting using ORDER BY queries too? Just
curious.
Regards,
Neha
On Tue, Feb 28, 2017 at 08:58:24AM -0800, Brandur Leach wrote:
> Hi Julien,
>
Hello Brandur,
> Thanks for the expedient reply, even after I'd dropped the
> ball for so long :)
:)
> Cool! I just re-read my own comment a few days later and I
> think that it still mostly makes sense, but definite
On Tue, Feb 28, 2017 at 10:28 PM, Brandur Leach wrote:
> * I've been generating a new OID value with the
> `unused_oids` script, but pretty much every time I rebase
> I collide with someone else's addition and need to find a
> new one. Is it better for me to pick an OID in an exotic
> rang
Hi Julien,
Thanks for the expedient reply, even after I'd dropped the
ball for so long :)
> Indeed, I should have checked more examples :/ There
> isn't any clear pattern for this, so I guess any one
> would be ok.
Yeah, agreed. If it's alright with you, I ended up moving
the naming back to `mac
On Sun, Feb 05, 2017 at 01:56:41PM -0800, Brandur Leach wrote:
Hello Brandur, thanks for the updated patch!
>
> > * you used macaddr_cmp_internal() function name, for uuid
> > the same function is named uuid_internal_cmp(). Using
> > the same naming pattern is probably better.
>
> I was a
And as a short follow up, I've moved the patch to the
current commit fest:
https://commitfest.postgresql.org/13/743/
On Sun, Feb 5, 2017 at 1:56 PM, Brandur Leach wrote:
> Hi Julien,
>
> Thank you for taking the time to do this review, and my
> apologies for the very delayed response. I lost t
Hi Julien,
Thank you for taking the time to do this review, and my
apologies for the very delayed response. I lost track of
this work and have only jumped back into it today.
Please find attached a new version of the patch with your
feedback integrated. I've also rebased the patch against
the cur
On Wed, Sep 14, 2016 at 6:14 AM, Julien Rouhaud
wrote:
> On 26/08/2016 19:44, Brandur wrote:
>> Hello,
> Hello,
>
>> I've attached a patch to add SortSupport for Postgres' macaddr which has the
>> effect of improving the performance of sorting operations for the type. The
>> strategy that I employ
On 26/08/2016 19:44, Brandur wrote:
> Hello,
>
Hello,
> I've attached a patch to add SortSupport for Postgres' macaddr which has the
> effect of improving the performance of sorting operations for the type. The
> strategy that I employ is very similar to that for UUID, which is to create
> abbre
And here's a commitfest link:
https://commitfest.postgresql.org/10/743/
Also, a correction to my original message: the unreferenced [1] footnote
points back to the thread that included the patch for UUID SortSupport.
[1]
https://www.postgresql.org/message-id/CAM3SWZR4avsTwwNVUzRNbHk8v36W-QBqpoK
Hello,
I've attached a patch to add SortSupport for Postgres' macaddr which has the
effect of improving the performance of sorting operations for the type. The
strategy that I employ is very similar to that for UUID, which is to create
abbreviated keys by packing as many bytes from the MAC address
19 matches
Mail list logo
