Hi,
On 2019-06-06 13:39:50 -0400, Tom Lane wrote:
> Lastly, I don't think adding additional allowed widths of pass-by-value
> types would be cost-free, because it would add cycles to the inner loops
> of the tuple forming and deforming functions.
I'm not sure I quite buy that.
I think that we ha
Andres Freund writes:
> On June 5, 2019 12:14:42 PM PDT, Alvaro Herrera
> wrote:
>> Does this mean that datatypes that are >4 and <=8 bytes need to handle
>> both cases? Is it possible for them to detect the current environment?
> Well, the conversion macros need to know. You can look at float
Hi,
On June 5, 2019 12:14:42 PM PDT, Alvaro Herrera
wrote:
>On 2019-Jun-05, Andres Freund wrote:
>
>> I'd much rather see this tackled in a general way than fiddling with
>> individual datatypes. I think we should:
>>
>> 1) make fetch_att(), store_att_byval() etc support datums of any
>length
>
On 2019-Jun-05, Andres Freund wrote:
> I'd much rather see this tackled in a general way than fiddling with
> individual datatypes. I think we should:
>
> 1) make fetch_att(), store_att_byval() etc support datums of any length
>between 1 and <= sizeof(Datum). Probably also convert them to inl
Hi,
On 2019-06-05 09:18:34 -0700, Melanie Plageman wrote:
> On Tue, Jun 4, 2019 at 3:50 PM Peter Geoghegan wrote:
>
> > On Tue, Jun 4, 2019 at 3:23 PM Andres Freund wrote:
> > > > This is half the reason why I ended up implementing itemptr_encode()
> > > > to accelerate the TID sort used by CRE
On 2019-Jun-05, Melanie Plageman wrote:
> I can take on making macaddr8 pass-by-value
> I tinkered a bit last night and got in/out mostly working (I think).
> I'm not sure about macaddr, TID, and user-defined types.
Yeah, let's see what macaddr8 looks like, and we can move from there --
I suppose
On Tue, Jun 4, 2019 at 3:50 PM Peter Geoghegan wrote:
> On Tue, Jun 4, 2019 at 3:23 PM Andres Freund wrote:
> > > This is half the reason why I ended up implementing itemptr_encode()
> > > to accelerate the TID sort used by CREATE INDEX CONCURRENTLY some
> > > years back -- TID is 6 bytes wide,
On Tue, Jun 4, 2019 at 3:23 PM Andres Freund wrote:
> > This is half the reason why I ended up implementing itemptr_encode()
> > to accelerate the TID sort used by CREATE INDEX CONCURRENTLY some
> > years back -- TID is 6 bytes wide, which doesn't have the necessary
> > macro support within postgr
Hi,
On 2019-06-04 15:10:07 -0700, Peter Geoghegan wrote:
> On Tue, Jun 4, 2019 at 2:55 PM Andres Freund wrote:
> > Yea, I don't immediately see a problem with doing that on a major
> > version boundary. Obviously that'd only be possible for sizeof(Datum) ==
> > 8 == sizeof(macaddr8) platforms, bu
On Tue, Jun 4, 2019 at 2:55 PM Andres Freund wrote:
> Yea, I don't immediately see a problem with doing that on a major
> version boundary. Obviously that'd only be possible for sizeof(Datum) ==
> 8 == sizeof(macaddr8) platforms, but that's the vast majority these
> days. And generally, I think it
Hi,
On 2019-06-04 14:55:16 -0700, Andres Freund wrote:
> On 2019-06-04 17:37:35 -0400, Alvaro Herrera wrote:
> I think it might be worthwhile to optimize things so that all typlen > 0
> && typlen <= sizeof(Datum) are allowed for byval datums.
Maybe even just deprecate specifying byval at CREATE T
Hi,
On 2019-06-04 17:37:35 -0400, Alvaro Herrera wrote:
> On 2019-Jun-03, Peter Geoghegan wrote:
> > As you know, it's a bit weird that we're proposing adding sort support
> > with abbreviated keys for a type that is 8 bytes, since you'd expect
> > it to also be pass-by-value on most platforms, wh
On 2019-Jun-03, Peter Geoghegan wrote:
> As you know, it's a bit weird that we're proposing adding sort support
> with abbreviated keys for a type that is 8 bytes, since you'd expect
> it to also be pass-by-value on most platforms, which largely defeats
> the purpose of having abbreviated keys (th
On Tue, Jun 04, 2019 at 01:49:23PM -0400, Stephen Frost wrote:
Greetings,
* Melanie Plageman (melanieplage...@gmail.com) wrote:
Peter and I implemented this small (attached) patch to extend
abbreviated key compare sort to macaddr8 datatype (currently supported
for macaddr).
Nice.
I think th
On Mon, Jun 3, 2019 at 2:39 PM Peter Geoghegan wrote:
>
> As you know, it's a bit weird that we're proposing adding sort support
> with abbreviated keys for a type that is 8 bytes, since you'd expect
> it to also be pass-by-value on most platforms, which largely defeats
> the purpose of having ab
Greetings,
* Melanie Plageman (melanieplage...@gmail.com) wrote:
> Peter and I implemented this small (attached) patch to extend
> abbreviated key compare sort to macaddr8 datatype (currently supported
> for macaddr).
Nice.
> I think that that seems like an improvement. I was thinking of
> regis
On Mon, Jun 3, 2019 at 2:59 PM Chapman Flack wrote:
> 1. (This one seems like a bug.) In the little-endian case, if
>SIZEOF_DATUM is smaller than the type, I'm not convinced by doing
>the DatumBigEndianToNative() after the memcpy(). Seems like that's
>too late to make sure the most-sig
On 6/3/19 5:59 PM, Chapman Flack wrote:
> On 6/3/19 5:03 PM, Chapman Flack wrote:
> 1. (This one seems like a bug.) In the little-endian case, if
>SIZEOF_DATUM is smaller than the type, I'm not convinced by doing
>the DatumBigEndianToNative() after the memcpy(). Seems like that's
>too l
On 6/3/19 5:03 PM, Chapman Flack wrote:
> On 6/3/19 3:23 PM, Melanie Plageman wrote:
>> Peter and I implemented this small (attached) patch to extend
>> abbreviated key compare sort to macaddr8 datatype (currently supported
>> for macaddr).
>
> Am I going cross-eyed, or would the memset be serving
On Mon, Jun 3, 2019 at 2:03 PM Chapman Flack wrote:
> Am I going cross-eyed, or would the memset be serving more of a purpose
> if it were in the SIZEOF_DATUM != 8 branch?
No, it wouldn't -- that's the correct place for it with the macaddr
type. However, it isn't actually necessary to memset() at
On Mon, Jun 3, 2019 at 1:17 PM Melanie Plageman
wrote:
> I tried checking to see if there is a performance difference using the
> attached DDL based on src/test/regress/sql/macaddr8.sql. I found
> that the sort function is only exercised when creating an index (not,
> for example, when doing some
On 6/3/19 3:23 PM, Melanie Plageman wrote:
> Peter and I implemented this small (attached) patch to extend
> abbreviated key compare sort to macaddr8 datatype (currently supported
> for macaddr).
Am I going cross-eyed, or would the memset be serving more of a purpose
if it were in the SIZEOF_DATUM
22 matches
Mail list logo
