Inf 8.3 the HOT feature may help if the columns being updated are
indexed ... what version of PostgreSQL is this again ? (Forgive my
lack of memory -- the last few days I've forgotten a lot, heh heh.)
8.3.5.
The colum that was being updated is part of one small index only.
Any chances
Laszlo Nagy wrote:
> >> My other idea was that there are so many indexes on this table, maybe
> >> the update is slow because of the indexes?
> >>
> >
> > Updating indexes is certainly very far from being free. How many is
> > "many"?
> >
> Number of indexes = 15.
>
> 3 indexex are on "
My other idea was that there are so many indexes on this table, maybe
the update is slow because of the indexes?
Updating indexes is certainly very far from being free. How many is
"many"?
Number of indexes = 15.
3 indexex are on "text" type column, 500MB in size each.
Other are on
The thing to keep in mind is that every update creates a new row version
that has to be indexed for all indexes on the table, not just the indexes on
the column updated. You can test the weight of indexes by copying the table
then trying your query again.
I've heard tell that if you have a table
Laszlo Nagy writes:
>> If the table has some sort of FK relations it might be being slowed by
>> the need to check a row meant to be deleted has any children.
>>
> If you look at my SQL, there is only one column to be updated. That
> column has no foreign key constraint.
That was not the quest
I just tested the same on a test machine. It only has one processor 1GB
memory, and one SATA disk. The same "select count(*)" was 58 seconds. I
started the same UPDATE with EXPLAIN ANALYZE. It is running since 1000
seconds. I'm now 100% sure that the problem is with the database,
because this m
If the table has some sort of FK relations it might be being slowed by
the need to check a row meant to be deleted has any children.
If you look at my SQL, there is only one column to be updated. That
column has no foreign key constraint. (It should have, but we did not
want to add that co
Laszlo Nagy wrote:
>
> Laszlo Nagy wrote:
> > SQL:
> >
> > update product set sz_category_id=null where am_style_kw1 is not null
> > and sz_category_id is not null
> Hmm, this query:
>
> ?select count(*) from product where am_style_kw1 is not null and
> sz_category_id is not null and sz_catego
Laszlo Nagy wrote:
SQL:
update product set sz_category_id=null where am_style_kw1 is not null
and sz_category_id is not null
Hmm, this query:
select count(*) from product where am_style_kw1 is not null and
sz_category_id is not null and sz_category_id<>4809
opens in 10 seconds. The update
SQL:
update product set sz_category_id=null where am_style_kw1 is not null
and sz_category_id is not null
query plan:
"Seq Scan on product (cost=0.00..647053.30 rows=580224 width=1609)"
" Filter: ((am_style_kw1 IS NOT NULL) AND (sz_category_id IS NOT NULL))"
Information on the table:
row
10 matches
Mail list logo
