update songs set views = 0;
UPDATE 54909
Time: 101907.837 ms
time is actually less than 10 minutes, but it is still very long :(
Wow.
test=> CREATE TABLE test (id SERIAL PRIMARY KEY, value INTEGER);
test=> INSERT INTO test (value) SELECT n FROM generate_series( 1,10 )
AS n;
Tem
The explain plan tree only shows the time to fetch/compute the new rows,
not to actually perform the update, update indexes, or fire triggers.
If there is a big discrepancy then the extra time must be going into
one of those steps.
8.1 does show trigger execution time separately, so the most ob
This is the critical point. You have this line:
There were 132969 unused item pointers.
Which says there's 132k or so dead rows in your table. Which means
vacuum / autovacuum isn't keeping up. Did you try and stop the update
several times? Each time it starts then gets killed it creates dead
This is the critical point. You have this line:
There were 132969 unused item pointers.
Which says there's 132k or so dead rows in your table. Which means
vacuum / autovacuum isn't keeping up. Did you try and stop the update
several times? Each time it starts then gets killed it creates dead
Od: [EMAIL PROTECTED]
> Komu: [EMAIL PROTECTED]
> CC: pgsql-performance@postgresql.org
> Datum: 12.11.2008 21:55
> Předmět: Re: [PERFORM] slow full table update
>
>On Mon, Nov 10, 2008 at 9:30 AM, <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I have table with
On Mon, Nov 10, 2008 at 9:30 AM, <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have table with cca 60.000 rows and
> when I run query as:
> Update table SET column=0;
> after 10 minutes i must stop query, but it still running :(
What does
vacuum verbose table;
say? I'm wondering if it's gotten overl
Richard Huxton <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> I try explain query with this result
>> for 10.000 rows > update songs set views = 0 where sid > 2 and sid <
>> 3
>>
>> Bitmap Heap Scan on songs (cost=151.59..6814.29 rows=8931 width=526)
>> (actual time=4.848..16
> >
> > Recheck Cond: ((sid > 2) AND (sid < 3))
> >
> > -> Bitmap Index Scan on pk_songs2 (cost=0.00..151.59 rows=8931
> width=0) (actual time=4.071..4.071 rows=9579 loops=1)
> >
> > Index Cond: ((sid > 2) AND (sid < 3))
> >
> > Is there a way to run this query on sigl
[EMAIL PROTECTED] wrote:
> Hi,
>
> I've changed settings,
> but with no effect on speed.
>
> I try explain query with this result
> for 10.000 rows > update songs set views = 0 where sid > 2 and sid < 3
>
> Bitmap Heap Scan on songs (cost=151.59..6814.29 rows=8931 width=526) (actual
>
throughpass with no Recheck Cond?
Thank you.
best regards
Marek Fiala
__
> Od: [EMAIL PROTECTED]
> Komu: pgsql-performance@postgresql.org
> Datum: 12.11.2008 17:48
> Předmět: Re: [PERFORM] slow full table update
>
>Hi,
Od: [EMAIL PROTECTED]
>> Komu: [EMAIL PROTECTED]
> > CC: pgsql-performance@postgresql.org
>> Datum: 10.11.2008 17:42
>> P�edm�t: Re: [PERFORM] slow full table update
>>
>>Sorry, but you have to provide much more information about the table. The
>>information you&
resql.org
> Datum: 10.11.2008 17:42
> Předmět: Re: [PERFORM] slow full table update
>
>Sorry, but you have to provide much more information about the table. The
>information you've provided is really not sufficient - the rows might be
>large or small. I guess it's the se
Sorry, but you have to provide much more information about the table. The
information you've provided is really not sufficient - the rows might be
large or small. I guess it's the second option, with a lots of dead rows.
Try this:
ANALYZE table;
SELECT relpages, reltuples FROM pg_class WHERE reln
Hi,
I have table with cca 60.000 rows and
when I run query as:
Update table SET column=0;
after 10 minutes i must stop query, but it still running :(
I've Postgres 8.1 with all default settings in postgres.conf
Where is the problem?
Thak you for any tips.
best regards.
Marek Fiala
--
14 matches
Mail list logo
