On Tue, 2024-09-03 at 10:39 +0530, veem v wrote:
> As you rightly said "they will make it more difficult to detach a partition."
> ,
> we are really seeing a longer time when detaching parent table partitions.
> It runs forever sometimes. So do you mean it's because we have primary key
> defined t
On Tue, 3 Sept 2024 at 01:14, Laurenz Albe wrote:
>
> You can keep the primary key defined on both columns if it is good enough
> for you.
> But it will give you lower guarantees of uniqueness: with that primary
> key, there could
> be two rows with a different timestamp, but the same "txn_id", a
On Mon, 2024-09-02 at 21:39 +0530, veem v wrote:
> On Mon, 2 Sept 2024 at 19:13, Laurenz Albe wrote:
> > On Sun, 2024-09-01 at 01:32 +0530, veem v wrote:
> > > due to postgres limitations we are unable to have this unique constraint
> > > or primary key
> > > only on the transaction_id column, we
On Mon, 2 Sept 2024 at 19:13, Laurenz Albe wrote:
> On Sun, 2024-09-01 at 01:32 +0530, veem v wrote:
> > due to postgres limitations we are unable to have this unique constraint
> or primary key
> > only on the transaction_id column, we have to include
> transaction_timestamp with it as
> > a com
On Sun, 2024-09-01 at 01:32 +0530, veem v wrote:
> due to postgres limitations we are unable to have this unique constraint or
> primary key
> only on the transaction_id column, we have to include transaction_timestamp
> with it as
> a composite key. So I want to understand from experts if there
On Sun, 1 Sept 2024 at 11:38, veem v wrote:
>
> On Sun, 1 Sept 2024 at 10:03, veem v wrote:
>
>>
>> On Sun, 1 Sept 2024 at 09:13, David G. Johnston <
>> david.g.johns...@gmail.com> wrote:
>>
>>> On Saturday, August 31, 2024, veem v wrote:
>>>
iii)And then alter the datatype of th
On Sun, 1 Sept 2024 at 10:03, veem v wrote:
>
> On Sun, 1 Sept 2024 at 09:13, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Saturday, August 31, 2024, veem v wrote:
>>
>>>
>>>
>>> iii)And then alter the datatype of the partition key transaction_date to
>>> DATE in one shot at
On Sun, 1 Sept 2024 at 09:13, David G. Johnston
wrote:
> On Saturday, August 31, 2024, veem v wrote:
>
>>
>>
>> iii)And then alter the datatype of the partition key transaction_date to
>> DATE in one shot at the table level(which should be fast as its having more
>> granularity as compare to exi
On Saturday, August 31, 2024, veem v wrote:
>
> 1) if it's technically possible to have a unique key on only the
> transaction_id column having the partition key on the
> transaction_timestamp, because the table is going to be queried/purged
> based on the transaction_timestamp?
>
There is prese
On Sun, 1 Sept 2024 at 03:58, Adrian Klaver
wrote:
>
> The model is at odds with itself and untenable. If the tables hold
> multiple rows for a given transaction_id then you cannot have a
> PK/Unique constraint on that column. Seems there is a decided lack of
> any planning. The only way I can s
On 8/31/24 13:02, veem v wrote:
Hello,
We have our transaction tables daily range partitioned based on
transaction_timestamp column which is timestamptz data type and these
are having composite primary key on (transaction_id,
transaction_timestamp). And we were using an "insert on conflict" f
Hello,
We have our transaction tables daily range partitioned based on
transaction_timestamp column which is timestamptz data type and these are
having composite primary key on (transaction_id, transaction_timestamp).
And we were using an "insert on conflict" for loading data to our system ,
which
12 matches
Mail list logo
