On 2024-Sep-14, yudhi s wrote:
> Hello,
> We have to update a column value(from numbers like '123' to codes like
> 'abc' by looking into a reference table data) in a partitioned table with
> billions of rows in it, with each partition having 100's millions rows.
Another option is to not update an
Hi,
You can solve this problem using Citus in PostgreSQL, which is specifically
designed for parallelism
SELECT create_distributed_table('tab_part1', 'partition_key');
SELECT create_distributed_table('reference_tab', 'reference_key');
UPDATE tab_part1
SET column1 = reftab.code
FROM reference_tab
On 2024-09-14 20:26:32 +0530, yudhi s wrote:
>
>
> On Sat, Sep 14, 2024 at 4:55 PM Peter J. Holzer wrote:
>
>
> Which in turn means that you want as little overhead as possible per
> batch which means finding those 5000 rows should be quick. Which brings
> us back to Igor's questio
The only way that I see as plausible to use a subquery, both in the query
and in the setting of the variable, is that the relationship is one to one,
and that there is an index that responds to the predicate
UPDATE table1 t1
SET column_value = (SELECT FROM table2 t2 WHERE t2.column_relation
= t1.
On Sat, 2024-09-14 at 16:10 +0530, yudhi s wrote:
> > However, the strain on your system's resources and particularly the row
> > locks will impair normal database work.
> >
> > Essentially, you can either take an extended down time or perform the
> > updates
> > in very small chunks with a very
On Sat, Sep 14, 2024 at 4:55 PM Peter J. Holzer wrote:
>
> Which in turn means that you want as little overhead as possible per
> batch which means finding those 5000 rows should be quick. Which brings
> us back to Igor's question: Do you have any indexes in place which speed
> up finding those 5
On Fri, Sep 13, 2024 at 11:59 PM yudhi s
wrote:
>
>>
>> Do you have any indexes?
>> If not - you should, if yes - what are they?
>>
>>
>>
> Yes we have a primary key on this table which is on a UUID type column and
> also we have other indexes in other timestamp columns . But how is this
> going
On 2024-09-14 16:10:15 +0530, yudhi s wrote:
> On Sat, 14 Sept, 2024, 1:09 pm Laurenz Albe, wrote:
>
> On Sat, 2024-09-14 at 08:43 +0530, yudhi s wrote:
> > We have to update a column value(from numbers like '123' to codes like
> 'abc'
> > by looking into a reference table data) i
On Sat, 14 Sept, 2024, 1:09 pm Laurenz Albe,
wrote:
> On Sat, 2024-09-14 at 08:43 +0530, yudhi s wrote:
> > We have to update a column value(from numbers like '123' to codes like
> 'abc'
> > by looking into a reference table data) in a partitioned table with
> billions
> > of rows in it, with eac
On Sat, 2024-09-14 at 08:43 +0530, yudhi s wrote:
> We have to update a column value(from numbers like '123' to codes like 'abc'
> by looking into a reference table data) in a partitioned table with billions
> of rows in it, with each partition having 100's millions rows. As we tested
> for ~30mil
>
>
>
> Do you have any indexes?
> If not - you should, if yes - what are they?
>
>
>
Yes we have a primary key on this table which is on a UUID type column and
also we have other indexes in other timestamp columns . But how is this
going to help as we are going to update almost all the rows in the
Hii,
On Fri, Sep 13, 2024 at 10:22 PM yudhi s wrote:
>
> Hello,
> We have to update a column value(from numbers like '123' to codes like 'abc'
> by looking into a reference table data) in a partitioned table with billions
> of rows in it, with each partition having 100's millions rows. As we te
Hello,
We have to update a column value(from numbers like '123' to codes like
'abc' by looking into a reference table data) in a partitioned table with
billions of rows in it, with each partition having 100's millions rows. As
we tested for ~30million rows it's taking ~20minutes to update. So if we
13 matches
Mail list logo
