On Thursday, July 8, 2021, Wiwwo Staff wrote:
> On Thu, 8 Jul 2021 at 21:42, Alban Hertroys com> wrote:
>
>> On 2021-07-08 13:30, Ron wrote:
>> > Thus, the bigTable PK must be on id, columnX, (No, I don't like it
>> > either.)
>>
>> That's not entirely true. You can keep the PK on id if you addi
On Thu, 8 Jul 2021 at 21:42, Alban Hertroys
wrote:
> On 2021-07-08 13:30, Ron wrote:
> > Thus, the bigTable PK must be on id, columnX, (No, I don't like it
> > either.)
>
> That's not entirely true. You can keep the PK on id if you additionally
> create a unique constraint on (id, columnX).
>
Uh
The docs are pretty clear that all constraints must have the partition key
as part of the key, and PK is most certainly a constraint.
I welcome a counter-example.
On 7/8/21 10:23 AM, Alban Hertroys wrote:
On 2021-07-08 13:30, Ron wrote:
> Thus, the bigTable PK must be on id, columnX, (No, I do
On 2021-07-08 13:30, Ron wrote:> Thus, the bigTable PK must be on id, columnX, (No, I don't like it > either.)That's not entirely true. You can keep the PK on id if you additionally create a unique constraint on (id, columnX).That way, you can at least be certain that the uniqueness of the PK remai
Big big variability on partitioned column, which is filtered (where
condition) in (almost) all queries.
On Thu, 8 Jul 2021 at 14:23, Michael Lewis wrote:
> Why are you using hash partitioning?
>
Why are you using hash partitioning?
On 7/8/21 3:42 AM, Wiwwo Staff wrote:
Hi!
I have a big table bigTable which I partitioned by hash on field columnX,
by creating bigTable_0, bigTable_1etc.
Since I need a PK on bigTable.id, and table is not partitioned by id, and
columnX is not unique, i added PK on bigTable_0.id, bigTable_1.id
Hi!
I have a big table bigTable which I partitioned by hash on field columnX,
by creating bigTable_0, bigTable_1 etc.
Since I need a PK on bigTable.id, and table is not partitioned by id, and
columnX is not unique, i added PK on bigTable_0.id, bigTable_1.id etc. So
far, so good.
Now I have another
