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
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
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
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
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
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
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
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
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
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
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
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
12 matches
Mail list logo
