On Sat, Jan 28, 2023 at 8:02 PM Ron wrote:
>
> Then it's not a Type 4 UUID, which is perfectly fine; just not random.
Yep, which is why it really should be re-versioned to UUIDv8 to be
pedantic. In everyday use though, almost certainly doesn't matter.
> Also, should now() be replaced by clock_ti
Then it's not a Type 4 UUID, which is perfectly fine; just not random.
Also, should now() be replaced by clock_timestamp(), so that it can be
called multiple times in the same transaction?
On 1/28/23 21:28, Miles Elam wrote:
On Sat, Jan 28, 2023 at 6:02 PM Ron wrote:
Type 4 UUIDs are sub-op
On Sat, Jan 28, 2023 at 6:02 PM Ron wrote:
>
> Type 4 UUIDs are sub-optimal for big table because cache hit rates drop
> through the floor.
>
> This lesson was burned into my psyche wy back in the Clinton
> administration. It was my task to speed up a five hour batch job which read
> input
Type 4 UUIDs are sub-optimal for big table because cache hit rates drop
through the floor.
This lesson was burned into my psyche wy back in the Clinton
administration. It was my task to speed up a five hour batch job which read
input records from a flat file, did some validations and then
Why is it a terrible idea? I have been using them for years without a
single problem. I don't rely on them for create order. Terrible seem a bit
extreme.
Thanks,
Ben
On Sat, Jan 28, 2023, 3:39 PM Erik Wienhold wrote:
> > On 27/01/2023 01:48 CET Ron wrote:
> >
> > On 1/26/23 15:55, Erik Wienhol
> On Jan 28, 2023, at 11:29, Miles Elam wrote:
> Why does this error result?
While the standard order of operations is to evaluate the WHERE before the
SELECT list, it's not guaranteed to result in short-cut execution. In
particular, constant folding happens very early in the processing of
> On 27/01/2023 01:48 CET Ron wrote:
>
> On 1/26/23 15:55, Erik Wienhold wrote:
> >
> > There are arguments against sequential PK, e.g. they give away too much
> > info and
> > allow attacks such as forced browsing[2]. The first I can understand: you
> > may
> > not want to reveal the number of
> On 28/01/2023 20:29 CET Miles Elam wrote:
>
> Postgres v15
>
> Given this example of a conversion from a byte array to an int8
> masquerading as an "unsigned" int4
>
> SELECT (get_byte(bytes, byte_offset)::int8 << 24)
> | (get_byte(bytes, byte_offset + 1) << 16)
>
Postgres v15
Given this example of a conversion from a byte array to an int8
masquerading as an "unsigned" int4
SELECT (get_byte(bytes, byte_offset)::int8 << 24)
| (get_byte(bytes, byte_offset + 1) << 16)
| (get_byte(bytes, byte_offset + 2) << 8)
| (ge
