Pushed this.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
On 2022-Oct-26, Alvaro Herrera wrote:
> On 2022-Oct-25, Finnerty, Jim wrote:
>
> > Or if you know the frequencies of the highly frequent values of the
> > partitioning key at the time the partition bounds are defined, you
> > could define hash ranges that contain approximately the same number of
On 2022-Oct-25, Finnerty, Jim wrote:
> Or if you know the frequencies of the highly frequent values of the
> partitioning key at the time the partition bounds are defined, you
> could define hash ranges that contain approximately the same number of
> rows in each partition. A parallel sequential
Or if you know the frequencies of the highly frequent values of the
partitioning key at the time the partition bounds are defined, you could define
hash ranges that contain approximately the same number of rows in each
partition. A parallel sequential scan of all partitions would then perform
It will often happen that some hash keys are more frequently referenced than
others. Consider a scenario where customer_id is the hash key, and one
customer is very large in terms of their activity, like IBM, and other keys
have much less activity. This asymmetry creates a noisy neighbor probl
Alvaro Herrera writes:
> On 2022-Oct-24, Finnerty, Jim wrote:
>> The advantage of hash partition bounds is that they are not
>> domain-specific, as they are for ordinary RANGE partitions, but they
>> are more flexible than MODULUS/REMAINDER partition bounds.
I'm more than a bit skeptical of that
On 2022-Oct-24, Finnerty, Jim wrote:
> Is there a reason why HASH partitioning does not currently support
> range partition bounds, where the values in the partition bounds would
> refer to the hashed value?
Just lack of an implementation, I suppose.
> The advantage of hash partition bounds is t
Is there a reason why HASH partitioning does not currently support range
partition bounds, where the values in the partition bounds would refer to the
hashed value?
The advantage of hash partition bounds is that they are not domain-specific,
as they are for ordinary RANGE partitions, but they
On Fri, 21 Oct 2022 at 20:34, Justin Pryzby wrote:
> On Fri, Oct 21, 2022 at 06:22:44PM +0800, Japin Li wrote:
>> Is there any way to get the regression tests diffs from Cirrus CI?
>> I did not find the diffs in [1].
>>
>> [1] https://cirrus-ci.com/build/4721735111540736
>
> They're called "mai
On Fri, Oct 21, 2022 at 06:22:44PM +0800, Japin Li wrote:
> Is there any way to get the regression tests diffs from Cirrus CI?
> I did not find the diffs in [1].
>
> [1] https://cirrus-ci.com/build/4721735111540736
They're called "main".
I'm planning on submitting a patch to rename it to "regress
headerscheck fail, fixed here.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
#error "Operator lives in the wrong universe"
("Use of cookies in real-time system development", M. Gleixner, M. Mc Guire)
>From c434020fc07616cdd13017135819083186d33256 Mon Sep 17 00
On 2022-Oct-21, Japin Li wrote:
> Is there any way to get the regression tests diffs from Cirrus CI?
> I did not find the diffs in [1].
I think they should be somewhere in the artifacts, but I'm not sure.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"La prime
On Fri, 21 Oct 2022 at 18:12, Alvaro Herrera wrote:
> On 2022-Oct-21, Japin Li wrote:
>
>> Does there an error about forget the LIST partition?
>
> Of course.
> https://cirrus-ci.com/build/4721735111540736
>
> This is what you get for moving cases around at the last minute ...
>
Is there any wa
On 2022-Oct-21, Japin Li wrote:
> Does there an error about forget the LIST partition?
Of course.
https://cirrus-ci.com/build/4721735111540736
This is what you get for moving cases around at the last minute ...
Fixed, thanks.
--
Álvaro Herrera PostgreSQL Developer — https://www.Ente
On Fri, 21 Oct 2022 at 17:32, Alvaro Herrera wrote:
> Hello
>
> I've had this patch sitting in a local branch for way too long. It's a
> trivial thing but for some reason it bothered me: we let the partition
> strategy flow into the backend as a string and only parse it into the
> catalog 1-ch
Hello
I've had this patch sitting in a local branch for way too long. It's a
trivial thing but for some reason it bothered me: we let the partition
strategy flow into the backend as a string and only parse it into the
catalog 1-char version quite late.
This patch makes gram.y responsible for pa
16 matches
Mail list logo