On 12/25/2015 03:23 AM, Ildus Kurbangaliev wrote:
On Fri, 25 Dec 2015 13:34:25 +0300
Teodor Sigaev wrote:
First, variables (high and low) should not be declared in the middle
of code. Second, assert will fail if ua.v64[0] == ub.v64[0] and
ua.v64[1] > ub.v64[1] although it's a possible and allow
On Fri, 25 Dec 2015 13:34:25 +0300
Teodor Sigaev wrote:
> Thank you, but I have some notices about
> static float
> uuid_parts_distance(pg_uuid_t *a, pg_uuid_t *b)
> {
> pg_uuid_t ua, ub;
> const double mp = pow(2, -64);
>
> uuid_cnv(a, &ua);
> uuid_cnv(b, &ub);
>
> Ass
Thank you, but I have some notices about
static float
uuid_parts_distance(pg_uuid_t *a, pg_uuid_t *b)
{
pg_uuid_t ua, ub;
const double mp = pow(2, -64);
uuid_cnv(a, &ua);
uuid_cnv(b, &ub);
Assert(ua.v64[0] > ub.v64[0]);
uint64 high = ua.v64[0] - ub.v64[0];
uint64 low
On Wed, 23 Dec 2015 16:36:23 -0800
Paul Jungwirth wrote:
> On 12/23/2015 08:10 AM, Ildus Kurbangaliev wrote:
> > There is a more improved version of the patch. Main idea is to
> > present uuid as two uint64 values, and make comparisons and penalty
> > calculation based on these values. This appro
On 12/23/2015 08:10 AM, Ildus Kurbangaliev wrote:
There is a more improved version of the patch. Main idea is to present
uuid as two uint64 values, and make comparisons and penalty calculation
based on these values. This approach is much faster than using memcmp
for uuid comparisons.
Thank you
On Tue, 15 Sep 2015 09:03:00 +0300
Teodor Sigaev wrote:
> Paul Jungwirth wrote:
> >> Or something like this in pseudocode:
> >>
> >> numeric = int8_numeric(*(uint64 *)(&i->data[0])) *
> >> int8_numeric(MAX_INT64) + int8_numeric(*(uint64 *)(&i->data[8]))
> >
> > This is more like what I was hopi
On Tue, Sep 15, 2015 at 3:03 PM, Teodor Sigaev wrote:
>
>
> Paul Jungwirth wrote:
>>>
>>> Or something like this in pseudocode:
>>>
>>> numeric = int8_numeric(*(uint64 *)(&i->data[0])) *
>>> int8_numeric(MAX_INT64) + int8_numeric(*(uint64 *)(&i->data[8]))
>>
>>
>> This is more like what I was hopi
Paul Jungwirth wrote:
Or something like this in pseudocode:
numeric = int8_numeric(*(uint64 *)(&i->data[0])) *
int8_numeric(MAX_INT64) + int8_numeric(*(uint64 *)(&i->data[8]))
This is more like what I was hoping for, rather than converting to a
string and back. Would you mind confirming for
Or something like this in pseudocode:
numeric = int8_numeric(*(uint64 *)(&i->data[0])) *
int8_numeric(MAX_INT64) + int8_numeric(*(uint64 *)(&i->data[8]))
This is more like what I was hoping for, rather than converting to a
string and back. Would you mind confirming for me: int8_numeric turns a
Paul Jungwirth wrote:
2)
static double
uuid2num(const pg_uuid_t *i)
{
return *((uint64 *)i);
}
It isn't looked as correct transformation for me. May be, it's better
to transform to numeric type (UUID looks like a 16-digit hexademical
number)
and follow
2)
static double
uuid2num(const pg_uuid_t *i)
{
return *((uint64 *)i);
}
It isn't looked as correct transformation for me. May be, it's better
to transform to numeric type (UUID looks like a 16-digit hexademical
number)
and follow gbt_numeric_penalty() log
Andres Freund wrote:
Please post reviews to the original thread unless that's already humongously
large.
I've lost original mail. Sorry.
Otherwise somebody needs to manually link up the threads in the CF application.
Of course, I did it
It also makes it much harder to follow the develo
Please post reviews to the original thread unless that's already humongously
large. Otherwise somebody needs to manually link up the threads in the CF
application.
It also makes it much harder to follow the development because there'll likely
be a new version of the patch after a review. Which
http://www.postgresql.org/message-id/flat/ca+renyvephxto1c7dfbvjp1gymuc0-3qdnwpn30-noo5mpy...@mail.gmail.com#ca+renyvephxto1c7dfbvjp1gymuc0-3qdnwpn30-noo5mpy...@mail.gmail.com
Patch looks perfect but it's still needed some work.
0) rebase to current HEAD (done, in attach)
1) UUIDSIZE -> UUID_LE
14 matches
Mail list logo
