On Apr 3, 2006, at 10:10 PM, Mark Kirkwood wrote:
I've always left them on, and never had any issues...(even after
unscheduled power loss - which happened here yesterday). As I
understand it, the softupdate code reorders *metadata* operations,
and does not alter data operations - so the ef
I have a table with 1 live row that I found has 115000 dead rows in it (
from a testing run ). I'm trying to VACUUM FULL the table and it has
run for over 18 hours without completion. Considering the hardware on
this box and the fact that performance seems reasonable in all other
aspects, I'm
Dan Harris wrote:
> I have a table with 1 live row that I found has 115000 dead rows in it (
> from a testing run ). I'm trying to VACUUM FULL the table and it has
> run for over 18 hours without completion. Considering the hardware on
> this box and the fact that performance seems reasonable in
On Tue, 2006-04-04 at 08:59 -0600, Dan Harris wrote:
> I have a table with 1 live row that I found has 115000 dead rows in it (
> from a testing run ). I'm trying to VACUUM FULL the table and it has
> run for over 18 hours without completion. Considering the hardware on
> this box and the fact
The datatype of the join columns is a user defined type and there are no
commutators defined. I will fix that and retest. Thanks for the
insight.
Mike Quinn
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://w
I have relatively small tables (toode and rid) in fast server.
Both tables are indexed on toode field.
Following query takes long time to run.
toode field type is char(20). It is difficult to change this field type.
Any idea how to speed up this query ?
UPDATE firma1.rid SET toode=NULL
WH
On Tue, 2006-04-04 at 14:37, Andrus wrote:
> I have relatively small tables (toode and rid) in fast server.
> Both tables are indexed on toode field.
>
> Following query takes long time to run.
> toode field type is char(20). It is difficult to change this field type.
>
> Any idea how to speed up
Wondering if
Update firma1.rid set toode=null where toode is not null and not
exists(select 1 from firma1.toode where toode=rid.toode);
Would be faster... Problem appears to be the seqscan of seqscan... No?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On B
Explain analyze would be nice ;-)
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrus
> Sent: Tuesday, April 04, 2006 3:37 PM
> To: pgsql-performance@postgresql.org
> Subject: [PERFORM] Query runs too long for indexed tables
>
> I have relative
On Apr 2, 2006, at 6:30 PM, Josh Berkus wrote:
But just as a follow up question to your #1 suggestion, I have 8 GB
of ram in my production server. You're saying to set the
effective_cache_size then to 5 GB roughly? Somewhere around 655360?
Currently it is set to 65535. Is that something that's OS
On Apr 1, 2006, at 12:51 PM, Brendan Duddridge wrote:
from SELECT * FROM pg_stats WHERE tablename='table' AND
attname='category_id'
I find correlation on category_product for category_id is 0.643703
Would setting the index on category_id to be clustered help with this?
It would absolutely h
version
PostgreSQL 8.1.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC)
3.3.6
(1 row)
-- After commutator added to operators of user defined type,
-- the orde
12 matches
Mail list logo
