From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: ANY_VALUE aggregate |
Date: | 2022-12-06 03:46:37 |
Message-ID: | ffddcf31-d170-9cf0-f6b6-985cd9e5be46@postgresfriends.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/5/22 18:56, David G. Johnston wrote:
> Also, maybe we should have any_value do something like compute a 50/50
> chance that any new value seen replaces the existing chosen value, instead
> of simply returning the first value all the time. Maybe even prohibit the
> first value from being chosen so long as a second value appears.
The spec says the result is implementation-dependent meaning we don't
even need to document how it is obtained, but surely behavior like this
would preclude future optimizations like the ones I mentioned?
I once wrote a random_agg() for a training course that used reservoir
sampling to get an evenly distributed value from the inputs. Something
like that seems to be what you are looking for here. I don't see the
use case for adding it to core, though.
The use case for ANY_VALUE is compliance with the standard.
--
Vik Fearing
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-12-06 03:51:16 | Re: Perform streaming logical transactions by background workers and parallel apply |
Previous Message | Masahiko Sawada | 2022-12-06 03:18:05 | Re: Add index scan progress to pg_stat_progress_vacuum |