[PERFORM] Question about CLUSTER

2008-02-11 Thread salman

Hello,

I'm planning to cluster a few large tables in our database but I'm
unable to find any recommendations/documentation on best practices --
Mainly, whether it's better to use an index which has a higher idx_scan
value, a higher idx_tup_read value, or the higest idx_tup_fetch value.

I'm assuming that idx_tup_read would probably be the best choice, but 
want to get other opinions before proceeding.


Can anyone point me to docs which explain this better?

-salman



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: [PERFORM] Replication Syatem

2008-04-28 Thread salman

Gauri Kanekar wrote:

Peter,

We are doing vacuum full every alternate day. We also do vacuum analyze very
often.
We are currently using 8.1.3 version.
Auto vacuum is already on. But the table1 is so busy that auto vacuum don't
get sufficient chance to vacuum it :(.

Have already tried all the option listed by you, thats y we reached to the
decision of having a replication sytsem. So any suggestion on that :).

Thanx
~ Gauri



We use slony for exactly this type of a situation. It's not the most 
user-friendly piece of software, but it works well enough that I can 
schedule maintenance windows (we're a 24/7 shop) and do clustering and 
other tasks on our DB to reclaim space, etc.


-salman

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


Re: [PERFORM] Problem with 11 M records table

2008-05-13 Thread salman



idc danny wrote:

Hi everybody,

I'm fairly new to PostgreSQL and I have a problem with
a query:

SELECT * FROM "LockerEvents" LIMIT 1 OFFSET
1099

The table LockerEvents has 11 Mlillions records on it
and this query takes about 60 seconds to complete.
Moreover, even after making for each column in the
table a index the EXPLAIN still uses sequential scan
instead of indexes.

The EXPLAIN is:
"Limit  (cost=100245579.54..100245803.00 rows=1
width=60) (actual time=58414.753..58482.661 rows=1
loops=1)"
"  ->  Seq Scan on "LockerEvents" 
(cost=1.00..100245803.00 rows=1100

width=60) (actual time=12.620..45463.222 rows=1100
loops=1)"
"Total runtime: 58493.648 ms"

The table is:

CREATE TABLE "LockerEvents"
(
  "ID" serial NOT NULL,
  "IDMoneySymbol" integer NOT NULL,
  "IDLocker" integer NOT NULL,
  "IDUser" integer NOT NULL,
  "IDEventType" integer NOT NULL,
  "TimeBegin" timestamp(0) without time zone NOT NULL,
  "Notes" character varying(200),
  "Income" double precision NOT NULL DEFAULT 0,
  "IncomeWithRate" double precision NOT NULL DEFAULT
0,
  CONSTRAINT pk_lockerevents_id PRIMARY KEY ("ID"),
  CONSTRAINT fk_lockerevents_ideventtype_eventtypes_id
FOREIGN KEY ("IDEventType")
  REFERENCES "EventTypes" ("ID") MATCH SIMPLE
  ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT fk_lockerevents_idlocker_lockers_id
FOREIGN KEY ("IDLocker")
  REFERENCES "Lockers" ("ID") MATCH SIMPLE
  ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT
fk_lockerevents_idmoneysymbol_moneysymbols_id FOREIGN
KEY ("IDMoneySymbol")
  REFERENCES "MoneySymbols" ("ID") MATCH SIMPLE
  ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT fk_lockerevents_iduser_users_id FOREIGN
KEY ("IDUser")
  REFERENCES "Users" ("ID") MATCH SIMPLE
  ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);


CREATE INDEX idx_col_lockerevents_income
  ON "LockerEvents"
  USING btree
  ("Income");

CREATE INDEX idx_col_lockerevents_incomewithrate
  ON "LockerEvents"
  USING btree
  ("IncomeWithRate");

CREATE INDEX idx_col_lockerevents_notes
  ON "LockerEvents"
  USING btree
  ("Notes");

CREATE INDEX idx_col_lockerevents_timebegin
  ON "LockerEvents"
  USING btree
  ("TimeBegin");

CREATE INDEX
idx_fk_lockerevents_ideventtype_eventtypes_id
  ON "LockerEvents"
  USING btree
  ("IDEventType");

CREATE INDEX idx_fk_lockerevents_idlocker_lockers_id
  ON "LockerEvents"
  USING btree
  ("IDLocker");

CREATE INDEX
idx_fk_lockerevents_idmoneysymbol_moneysymbols_id
  ON "LockerEvents"
  USING btree
  ("IDMoneySymbol");

CREATE INDEX idx_fk_lockerevents_iduser_users_id
  ON "LockerEvents"
  USING btree
  ("IDUser");

CREATE UNIQUE INDEX idx_pk_lockerevents_id
  ON "LockerEvents"
  USING btree
  ("ID");


If I do the query :
SELECT * FROM "LockerEvents" LIMIT 1 OFFSET 0
then this query takes under a second to complete - I
believe this is because the sequential scan starts
from beginning.

I need the query to complete under 10 seconds and I do
not know how to do it. 
Please help me!


Thank you,
Danny



I recall it being mentioned on one of these lists that with offset, all 
the rows in between still have to be read. So, you may get better 
results if you use a 'where id > 1' clause in the query.


-salman


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


Re: [PERFORM] The state of PG replication in 2008/Q2?

2008-08-21 Thread salman



Mathias Stjernström wrote:
Yes thats true. It does support DDL changes but not in a automatic way. 
You have to execute all DDL changes with a separate script.




That's true, but it's quite simple to do with the provided perl 
script(s) - slonik_execute_script. I've had to make use of it a few 
times and have had no problems.


-salman

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance