Henrik wrote:
>
> 6 dec 2007 kl. 20.26 skrev Alvaro Herrera:
>
>> Henrik wrote:
>>
>>> I think I have a clue why its so off. We update a value in that table
>>> about
>>> 2 - 3 million times per night and as update creates a new row it becomes
>>> bloated pretty fast. The table hade a size of 765
6 dec 2007 kl. 20.26 skrev Alvaro Herrera:
Henrik wrote:
I think I have a clue why its so off. We update a value in that
table about
2 - 3 million times per night and as update creates a new row it
becomes
bloated pretty fast. The table hade a size of 765 MB including
indexes and
after
6 dec 2007 kl. 22.18 skrev Alvaro Herrera:
Gauthier, Dave wrote:
Future Enhancement?
If the column's new value can fit in the space already being used
by the
existing value, just change the column value in place and leave the
record alone. Would reduce the need for vacuum in many cases.
Gauthier, Dave wrote:
> Future Enhancement?
> If the column's new value can fit in the space already being used by the
> existing value, just change the column value in place and leave the
> record alone. Would reduce the need for vacuum in many cases.
That's in 8.3. Not exactly like that (becau
EMAIL PROTECTED] On Behalf Of Alvaro Herrera
Sent: Thursday, December 06, 2007 2:26 PM
To: Henrik
Cc: Tom Lane; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Nested loop in simple query taking long time
Henrik wrote:
> I think I have a clue why its so off. We update a value in that table
about
Henrik wrote:
> I think I have a clue why its so off. We update a value in that table about
> 2 - 3 million times per night and as update creates a new row it becomes
> bloated pretty fast. The table hade a size of 765 MB including indexes and
> after vacuum full and reindex it went down to 80k
6 dec 2007 kl. 18.12 skrev Tom Lane:
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
5 dec 2007 kl. 16.25 skrev Tom Lane:
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
-> Bitmap Index Scan on tbl_archive_idx1
(cost=0.00..1150.47 rows=8 width=0) (actual time=1505.456..1505.456
rows=86053 loops=1
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
> 5 dec 2007 kl. 16.25 skrev Tom Lane:
>> Henrik Zagerholm <[EMAIL PROTECTED]> writes:
>>> -> Bitmap Index Scan on tbl_archive_idx1
>>> (cost=0.00..1150.47 rows=8 width=0) (actual time=1505.456..1505.456
>>> rows=86053 loops=16)
>>> Index Cond: (tbl_sha
5 dec 2007 kl. 16.25 skrev Tom Lane:
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
Usually I can see what is wrong with queries but I can't figure out
why this query is slow.
Seems the main problem is here:
-> Bitmap Index Scan on tbl_archive_idx1
(cost=0.00..1150.47 ro
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
> Usually I can see what is wrong with queries but I can't figure out
> why this query is slow.
Seems the main problem is here:
> -> Bitmap Index Scan on tbl_archive_idx1
> (cost=0.00..1150.47 rows=8 width=0) (actual time=150
Hello list,
Usually I can see what is wrong with queries but I can't figure out
why this query is slow.
Below is query and explain analyze output.
Any help would be appreciated.
EXPLAIN ANALYZE SELECT computer_name
FROM tbl_computer
INNER JOIN tbl_share ON pk_computer_id = tbl_share.fk_comput
11 matches
Mail list logo
