Re: PostgreSQL performance problem -> tuning

Hi All!

First, thanks for answers.

Richard Huxton wrote:

> On Wednesday 06 August 2003 08:34, Yaroslav Mazurak wrote:

> Version 7.3.4 is just out - probably worth upgrading as soon as it's
> convenient.

Has version 7.3.4 significant performance upgrade relative to 7.3.2?
I've downloaded version 7.3.4, but not installed yet.

>>sort_mem = 131072

> This sort_mem value is *very* large - that's 131MB for *each sort* that gets
> done. I'd suggest trying something in the range 1,000-10,000. What's probably
> happening with the error above is that PG is allocating ridiculous amounts of
> memory, the machines going into swap and everything eventually grinds to a
> halt.

What mean "each sort"? Each query with SORT clause or some internal
(invisible to user) sorts too (I can't imagine: indexed search or
whatever else)?
I'm reduced sort_mem to 16M.

>>fsync = false

> I'd turn fsync back on - unless you don't mind losing your data after a crash.

This is temporary performance solution - I want get SELECT query result
first, but current performance is too low.

>>enable_seqscan = false

> Don't tinker with these in a live system, they're only really for
> testing/debugging.

This is another strange behavior of PostgreSQL - he don't use some
created indexes (seq_scan only) after ANALYZE too. OK, I'm turned on
this option back.

>>effective_cache_size = 65536

> So you typically get about 256MB cache usage in top/free?

No, top shows 12-20Mb.
I'm reduced effective_cache_size to 4K blocks (16M?).

>> SELECT statement is:
>>
>>SELECT showcalc('B00204', dd, r020, t071) AS s04
>>FROM v_file02wide
>>WHERE a011 = 3
>> AND inrepdate(data)
>> AND SUBSTR(ncks, 2, 2) IN ('NL', 'NM')
>> AND r030 = 980;

> Hmm - mostly views and function calls, OK - I'll read on.

My data are distributed accross multiple tables to integrity and avoid
redundancy. During SELECT query these data rejoined to be presented in
"human-readable" form. :)
"SUBSTR" returns about 25 records, I'm too lazy for write 25 numbers.
:) I'm also worried for errors.

>>(cost=174200202474.99..174200202474.99 rows=1 width=143) -> Hash Join

> ^^^^^^^
> This is a BIG cost estimate and you've got lots more like them. I'm guessing
> it's because of the sort_mem / enable_seqscan settings you have. The numbers
> don't make sense to me - it sounds like you've pushed the cost estimator into
> a very strange corner.

I think that cost estimator "pushed into very strange corner" by himself.

>> Function showcalc definition is:

>>CREATE OR REPLACE FUNCTION showcalc(VARCHAR(10), VARCHAR(2), VARCHAR(4),
>>NUMERIC(16)) RETURNS NUMERIC(16)
>>LANGUAGE SQL AS '
>>-- Parameters: code, dd, r020, t071
>> SELECT COALESCE(
>> (SELECT sc.koef * $4
>> FROM showing AS s NATURAL JOIN showcomp AS sc
>> WHERE s.kod LIKE $1
>> AND NOT SUBSTR(acc_mask, 1, 1) LIKE ''[''
>> AND SUBSTR(acc_mask, 1, 4) LIKE $3
>> AND SUBSTR(acc_mask, 5, 1) LIKE SUBSTR($2, 1, 1)),

> Obviously, you could use = for these 3 rather than LIKE ^^^
> Same below too.

>> (SELECT SUM(sc.koef * COALESCE(showcalc(SUBSTR(acc_mask, 2,
>>LENGTH(acc_mask) - 2), $2, $3, $4), 0))
>> FROM showing AS s NATURAL JOIN showcomp AS sc
>> WHERE s.kod LIKE $1
>> AND SUBSTR(acc_mask, 1, 1) LIKE ''[''),
>> 0) AS showing;
>>';

OK, all unnecessary "LIKEs" replaced by "=", JOIN removed too:
CREATE OR REPLACE FUNCTION showcalc(VARCHAR(10), VARCHAR(2), VARCHAR(4),
NUMERIC(16)) RETURNS NUMERIC(16)
LANGUAGE SQL AS '
-- Parameters: code, dd, r020, t071
SELECT COALESCE(
(SELECT sc.koef * $4
FROM showing AS s, showcomp AS sc
WHERE sc.kod = s.kod
AND s.kod LIKE $1
AND NOT SUBSTR(acc_mask, 1, 1) = ''[''
AND SUBSTR(acc_mask, 1, 4) = $3
AND SUBSTR(acc_mask, 5, 1) = SUBSTR($2, 1, 1)),
(SELECT SUM(sc.koef * COALESCE(showcalc(SUBSTR(acc_mask, 2,
LENGTH(acc_mask) - 2), $2, $3, $4), 0))
FROM showing AS s, showcomp AS sc
WHERE sc.kod = s.kod
AND s.kod = $1
AND SUBSTR(acc_mask, 1, 1) = ''[''),
0) AS showing;
';

>> View v_file02wide is:

>>CREATE VIEW v_file02wide AS
>>SELECT id_a011 AS a011, data, obl.ko, obl.nazva AS oblast, b030,
>>banx.box AS ncks, banx.nazva AS bank,
>> epr.dd, r020, r030, a3, r030.nazva AS valuta, k041,
>> -- Sum equivalent in national currency
>> t071 * get_kurs(id_r030, data) AS t070,
>> t071
>>FROM v_file02 AS vf02
>> JOIN kod_obl AS obl USING(id_obl)
>> JOIN (dov_bank NATURAL JOIN dov_tvbv) AS banx
>> ON banx.id_v = vf02.id_v
>> AND data BETWEEN COALESCE(banx.dataa, data)
>> AND COALESCE(banx.datab, data)
>> JOIN ek_pok_r AS epr USING(id_dd)
>> JOIN kl_r020 USING(id_r020)
>> JOIN kl_r030 AS r030 USING(id_r030)
>> JOIN kl_k041 USING(id_k041);

> You might want to rewrite the view so it doesn't use explicit JOIN statements,
> i.e FROM a,b WHERE a.id=b.ref rather than FROM a JOIN b ON id=ref
> At the moment, this will force PG into making the joins in the order you write
> them (I think this is changed in v7.4)

I think this is a important remark. Can "JOIN" significantly reduce
performance of SELECT statement relative to ", WHERE"?
OK, I'm changed VIEW to this text:

CREATE VIEW v_file02 AS
SELECT filenum, data, id_a011, id_v, id_obl, id_dd, id_r020, id_r030,
id_k041, t071
FROM filexxr, file02
WHERE file02.id_r = filexxr.id_r;

CREATE VIEW v_file02wide AS
SELECT id_a011 AS a011, data, obl.ko, obl.nazva AS oblast, b030,
banx.box AS ncks, banx.nazva AS bank,
epr.dd, r020, vf02.id_r030 AS r030, a3, kl_r030.nazva AS valuta, k041,
-- Sum equivalent in national currency
t071 * get_kurs(vf02.id_r030, data) AS t070, t071
FROM v_file02 AS vf02, kod_obl AS obl, v_banx AS banx,
ek_pok_r AS epr, kl_r020, kl_r030, kl_k041
WHERE obl.id_obl = vf02.id_obl
AND banx.id_v = vf02.id_v
AND data BETWEEN COALESCE(banx.dataa, data)
AND COALESCE(banx.datab, data)
AND epr.id_dd = vf02.id_dd
AND kl_r020.id_r020 = vf02.id_r020
AND kl_r030.id_r030 = vf02.id_r030
AND kl_k041.id_k041 = vf02.id_k041;

Now (with configuration and view definition changed) "SELECT COUNT(*)
FROM v_file02wide;" executes about 6 minutes and 45 seconds instead of
30 seconds (previous).
Another annoying "feature" is impossibility writing "SELECT * FROM..."
- duplicate column names error. In NATURAL JOIN joined columns hiding
automatically. :-|

>> Function inrepdate is:

>>CREATE OR REPLACE FUNCTION inrepdate(DATE) RETURNS BOOL
>>LANGUAGE SQL AS '
>> -- Returns true if given date is in repdate
>> SELECT (SELECT COUNT(*) FROM repdate
>> WHERE $1 BETWEEN COALESCE(data1, CURRENT_DATE)
>> AND COALESCE(data2, CURRENT_DATE))
>>
>> > 0;

> You can probably replace this with:
> SELECT true FROM repdate WHERE $1 ...
> You'll need to look at where it's used though.

Hmm... table repdate contain date intervals. For example:
data1 data2
2003-01-01 2003-01-10
2003-05-07 2003-05-24
...
I need single value (true or false) about given date as parameter -
report includes given date or not. COUNT used as aggregate function for
this. Can you write this function more simpler?
BTW, I prefer SQL language if possible, then PL/pgSQL. This may be mistake?

>> Table has indexes almost for all selected fields.

> That's not going to help you for the SUBSTR(...) stuff, although you could use
> functional indexes (see manuals/list archives for details).

Yes, I'm using functional indexes, but not in this case... now in this
case too! :)

> First thing is to get those two configuration settings somewhere sane, then we
> can tune properly. You might like the document at:

> http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html

Thanks, it's interesting.

Current query plan:

QUERY PLAN

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=188411.98..188411.98 rows=1 width=151)
-> Hash Join (cost=186572.19..188398.39 rows=5437 width=151)
Hash Cond: ("outer".id_obl = "inner".id_obl)
-> Hash Join (cost=186570.65..188301.70 rows=5437 width=147)
Hash Cond: ("outer".id_dd = "inner".id_dd)
-> Hash Join (cost=186569.45..188205.34 rows=5437
width=137)
Hash Cond: ("outer".id_k041 = "inner".id_k041)
-> Hash Join (cost=186568.40..188109.14
rows=5437 width=133)
Hash Cond: ("outer".id_r020 = "inner".id_r020)
-> Hash Join (cost=186499.15..187944.74
rows=5437 width=122)
Hash Cond: ("outer".id_r030 =
"inner".id_r030)
-> Merge Join
(cost=186493.55..187843.99 rows=5437 width=118)
Merge Cond: ("outer".id_v =
"inner".id_v)
Join Filter: (("outer".data >=
CASE WHEN ("inner".dataa IS NOT NULL) THEN "inner".dataa WHEN
("outer".data IS NOT NULL) THEN "outer".data ELSE NULL::date END) AND
("outer".data <= CASE WHEN ("inner".datab IS NOT NULL) THEN
"inner".datab WHEN ("outer".data IS NOT NULL) THEN "outer".data ELSE
NULL::date END))
-> Sort
(cost=29324.30..29568.97 rows=97870 width=61)
Sort Key: filexxr.id_v
-> Hash Join
(cost=632.67..21211.53 rows=97870 width=61)
Hash Cond:
("outer".id_r = "inner".id_r)
-> Seq Scan on
file02 (cost=0.00..16888.16 rows=493464 width=32)
Filter:
(id_r030 = 980)
-> Hash
(cost=615.41..615.41 rows=6903 width=29)
-> Index Scan
using index_filexxr_a011 on filexxr (cost=0.00..615.41 rows=6903 width=29)
Index
Cond: (id_a011 = 3)
Filter:
inrepdate(data)
-> Sort
(cost=157169.25..157172.17 rows=1167 width=57)
Sort Key: v.id_v
-> Hash Join
(cost=1.18..157109.80 rows=1167 width=57)
Hash Cond:
("outer".id_oz = "inner".id_oz)
-> Merge Join
(cost=0.00..157088.20 rows=1167 width=53)
Merge Cond:
("outer".id_bnk = "inner".id_bnk)
-> Index Scan
using dov_bank_pkey on dov_bank b (cost=0.00..261328.45 rows=1450 width=17)
Filter:
(subplan)
SubPlan
->
Materialize (cost=90.02..90.02 rows=29 width=11)

-> Seq Scan on dov_bank (cost=0.00..90.02 rows=29 width=11)

Filter: ((dov_bank_box_22(box) = 'NL'::character varying) OR
(dov_bank_box_22(box) = 'NM'::character varying))
-> Index Scan
using index_dov_tvbv_bnk on dov_tvbv v (cost=0.00..142.42 rows=2334
width=36)
-> Hash
(cost=1.14..1.14 rows=14 width=4)
-> Seq Scan
on ozkb o (cost=0.00..1.14 rows=14 width=4)
-> Hash (cost=5.08..5.08 rows=208
width=4)
-> Seq Scan on kl_r030
(cost=0.00..5.08 rows=208 width=4)
-> Hash (cost=64.00..64.00 rows=2100 width=11)
-> Seq Scan on kl_r020
(cost=0.00..64.00 rows=2100 width=11)
-> Hash (cost=1.04..1.04 rows=4 width=4)
-> Seq Scan on kl_k041 (cost=0.00..1.04
rows=4 width=4)
-> Hash (cost=1.16..1.16 rows=16 width=10)
-> Seq Scan on ek_pok_r epr (cost=0.00..1.16
rows=16 width=10)
-> Hash (cost=1.43..1.43 rows=43 width=4)
-> Seq Scan on kod_obl obl (cost=0.00..1.43 rows=43
width=4)
(49 rows)

Now (2K shared_buffers blocks, 16K effective_cache_size blocks, 16Mb
sort_mem) PostgreSQL uses much less memory, about 64M... it's not good,
I want using all available RAM if possible - PostgreSQL is the main task
on this PC.
May set effective_cache_size to 192M (48K blocks) be better? I don't
understand exactly: effective_cache_size tells PostgreSQL about OS cache
size or about available free RAM?

With best regards
Yaroslav Mazurak.