On Sun, May 26, 2019 at 8:37 PM Tomas Vondra
wrote:
No, an extra column is not a solution, because it has no impact on the
> index on the UUID column.
Possibly talking at cross-purposes here. I was honing in on the OPs wish to
search and sort by creation order. For which my first (and only) ins
Here's what I was thinking of regarding disk space:
https://www.postgresql.org/docs/11/storage-page-layout.html
That's the kind of low-level detail I try *not* to worry about, but like to
have in the back of my mind at least a little. If I read it correctly, a
fixed-length field is going to be ma
On Sun, May 26, 2019 at 02:27:05PM +1000, Morris de Oryx wrote:
I'm not worthy to post here, but a bit of a random thought.
If I've followed the conversation correctly, the reason for a V1 UUID is
partly to order and partition rows by a timestamp value, but without the
cost of a timestamp column
On Sun, May 26, 2019 at 7:38 PM Ancoron Luciferis <
ancoron.lucife...@googlemail.com> wrote:
The BRIN index is something I might need to test, though.
>
Yes, check that out, it might give you some ideas. A B-tree (in whatever
variant) is *inherently *a large index type. They're ideal for finding
On 26/05/2019 06:27, Morris de Oryx wrote:
> I'm not worthy to post here, but a bit of a random thought.
>
> If I've followed the conversation correctly, the reason for a V1 UUID is
> partly to order and partition rows by a timestamp value, but without the
> cost of a timestamp column. As I was to
On 26/05/2019 03:09, Tomas Vondra wrote:
> On Sun, May 26, 2019 at 01:49:30AM +0200, Ancoron Luciferis wrote:
>> On 26/05/2019 00:14, Tomas Vondra wrote:
>>> On Sat, May 25, 2019 at 05:54:15PM -0400, Tom Lane wrote:
Ancoron Luciferis writes:
> On 25/05/2019 16:57, Tom Lane wrote:
>> (