On 27/07/2019 15:47, Tomas Vondra wrote:
> On Thu, Jul 25, 2019 at 11:26:23AM +0200, Ancoron Luciferis wrote:
>> Hi,
>>
>> I have finally found some time to implement a custom data type optimized
>> for version 1 UUID's (timestamp, clock sequence, node):
>>
Hi,
I have finally found some time to implement a custom data type optimized
for version 1 UUID's (timestamp, clock sequence, node):
https://github.com/ancoron/pg-uuid-v1
Some tests (using a few millions of rows) have shown the following
results (when used as a primary key):
COPY ... FROM: ~7.8x
On 06/07/2019 15:58, Tom Lane wrote:
> Ancoron Luciferis writes:
>> I've been wondering whether it is possible somehow to have the standard
>> column statistics to respect a certain operator class?
>
> In principle, pg_statistic can represent stats for a non-default o
On 08/07/2019 02:26, Peter Geoghegan wrote:
> Please don't top post -- trim the your response down so that only
> still-relevant text remains.
>
> On Tue, Jun 11, 2019 at 1:27 PM Ancoron Luciferis
> wrote:
>> Primary key indexes after an ANALYZE:
>> table_name
On 06/07/2019 17:57, Tomas Vondra wrote:
> On Sat, Jul 06, 2019 at 05:35:33PM +0200, Ancoron Luciferis wrote:
>> On 06/07/2019 15:38, Tomas Vondra wrote:
>>> On Sat, Jul 06, 2019 at 11:02:27AM +0200, Ancoron Luciferis wrote:
>>>> Hi,
>>>>
>>>>
On 06/07/2019 15:38, Tomas Vondra wrote:
> On Sat, Jul 06, 2019 at 11:02:27AM +0200, Ancoron Luciferis wrote:
>> Hi,
>>
>> I've been wondering whether it is possible somehow to have the standard
>> column statistics to respect a certain operator class?
>>
>
Hi,
I've been wondering whether it is possible somehow to have the standard
column statistics to respect a certain operator class?
The reason why I am asking for this is that I have a UUID column with a
unique index at it using a custom operator class which implies a
different sort order than for
to enable
time-wise index sort order. This will naturally be very close to
physical order but I doubt that this is something I can tell PostgreSQL, or?
Cheers,
Ancoron
On 26/05/2019 11:01, Ancoron Luciferis wrote:
> On 26/05/2019 03:09, Tomas Vondra wrote:
>> On Sun, May 26, 2019 a
t, though.
>
> Best of luck, I've enjoyed following the commentary.
>
>
> On Sun, May 26, 2019 at 11:09 AM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
> On Sun, May 26, 2019 at 01:49:30AM +0200, Ancoron Luciferis wrote:
>
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 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:
>>>> (4) it in fact *wouldn't* do anything useful, because we'd still have
>&
On 25/05/2019 23:54, Tom Lane wrote:
> Ancoron Luciferis writes:
>> On 25/05/2019 16:57, Tom Lane wrote:
>>> (4) it in fact *wouldn't* do anything useful, because we'd still have
>>> to sort UUIDs in the same order as today, meaning that btree index behavio
makes any sense to you or if I'm just missing a
piece of the puzzle inside the PostgreSQL code base. If I do, please
tell me. :)
Cheers,
Ancoron
>
> сб, 25 трав. 2019 о 11:21 Ancoron Luciferis
> <mailto:ancoron.lucife...@googlemail.com>> пише:
>
> On 25/0
makes any sense to you or if I'm just missing a
piece of the puzzle inside the PostgreSQL code base. If I do, please
tell me. :)
Cheers,
Ancoron
>
> сб, 25 трав. 2019 о 11:21 Ancoron Luciferis
> <mailto:ancoron.lucife...@googlemail.com>> пише:
>
> On 25/0
On 25/05/2019 16:57, Tom Lane wrote:
> Ancoron Luciferis writes:
>> So I investigated the PostgreSQL code to see how it is handling UUID's
>> with respect to storage, sorting, aso. but all I could find was that it
>> basically falls back to the 16-byte.
>
&g
On 25/05/2019 16:19, Peter Eisentraut wrote:
> On 2019-05-25 15:45, Ancoron Luciferis wrote:
>> So, my question now is: Would it make sense for you to handle these
>> time-based UUID's differently internally? Specifically un-shuffling the
>> timestamp before they are
Hi all,
Some time ago, I was having trouble with some rather high load OLTP
application (in Java, but that doesn't really matter) that was using v1
UUID's for primary keys and after some time, the bloat of certain
indexes went quite high.
So I investigated the PostgreSQL code to see how it is han
On 12/05/2019 20:08, Tom Lane wrote:
> Ancoron Luciferis writes:
>> One of the things consuming most of the time was an Index Only Scan
>> executed millions of times. And on top came the Nested Loop which
>> finally reduced the rows but also took a lot of time to do so.
>
Hi,
I recently stumbled across an interesting query performance question
over at StackOverflow [1], which caught my attention and I started to
investigate the issue further.
One of the things consuming most of the time was an Index Only Scan
executed millions of times. And on top came the Nested
19 matches
Mail list logo
