Re: [PERFORM] Query that took a lot of time in Postgresql when not using trim in order by

2015-11-29 Thread Peter J. Holzer
2 Dual, so a rather old and slow box) and I could sort 1E6 rows of 128 random bytes in 5.6 seconds. Even if I kept the first 96 bytes constant (so only the last 32 were random), it took only 21 seconds. Either this CPU is really slow or the data is heavily skewed - is it possible that all dimension

Re: [PERFORM] Different plan for very similar queries

2015-07-19 Thread Peter J. Holzer
On 2015-05-29 10:55:44 +0200, Peter J. Holzer wrote: > wdsah=> explain analyze select facttablename, columnname, term, concept_id, > t.hidden, language, register > from term t where facttablename='facttable_stat_fta4' and > columnname='einh

Re: [PERFORM] Different plan for very similar queries

2015-05-31 Thread Peter J. Holzer
e_stat_fta4_warenstrom_idx on facttable_stat_fta4 f (cost=0.00..2124100.90 rows=21787688 width=2) (actual time=0.029..0.029 rows=1 loops=3) Index Cond: ((warenstrom)::text = (t.term)::text) Total runtime: 0.180 ms (6 rows) The estimated number of rows in the outer scan is way more a

Re: [PERFORM] Different plan for very similar queries

2015-05-29 Thread Peter J. Holzer
On 2015-05-29 10:55:44 +0200, Peter J. Holzer wrote: > wdsah=> explain analyze select facttablename, columnname, term, concept_id, > t.hidden, language, register > from term t where facttablename='facttable_stat_fta4' and > columnname='einh

[PERFORM] Different plan for very similar queries

2015-05-29 Thread Peter J. Holzer
:text)) -> Index Scan using facttable_stat_fta4_berechnungsart_idx on facttable_stat_fta4 f (cost=0.00..2545748.85 rows=43577940 width=2) (actual time=0.089..16263.582 rows=21336180 loops=1) Total runtime: 30948.648 ms (6 rows) Over 30 seconds! That's almost 200'000 times slower. T