R: R: [PERFORM] Query plan on identical tables differs . Why ?

2004-05-14 Thread Fabio Panizzutti
>>>-Messaggio originale- >>>Da: Tom Lane [mailto:[EMAIL PROTECTED] >>>Inviato: giovedì 13 maggio 2004 17.01 >>>A: Fabio Panizzutti >>>Cc: 'Shridhar Daithankar'; [EMAIL PROTECTED] >>>Oggetto: Re: R: [PERFORM] Query plan on identical tables >>>differs . Why ? >>> >>> >>>"Fabio Panizzutti

R: R: [PERFORM] Query plan on identical tables differs . Why ?

2004-05-14 Thread Fabio Panizzutti
>>>-Messaggio originale- >>>Da: Stephan Szabo [mailto:[EMAIL PROTECTED] >>>Inviato: giovedì 13 maggio 2004 17.17 >>>A: Fabio Panizzutti >>>Cc: 'Shridhar Daithankar'; [EMAIL PROTECTED] >>>Oggetto: Re: R: [PERFORM] Query plan on identical tables >>>differs . Why ? >>> >>> >>>On Thu, 13 Ma

R: R: [PERFORM] Query plan on identical tables differs . Why ?

2004-05-14 Thread Fabio Panizzutti
Index Scan using pk_storico_misure_2 on storico_misure (cost=0.00..1984.64 rows=658 width=21) (actual >>>time=723.441..1858.107 rows=835 loops=1) Index Cond: ((data_tag > '2004-05-03 >>>00:00:00'::timestamp without time zone) AND (data_tag < '2004-05-12 00:00:00'::tim

Re: R: R: [PERFORM] Query plan on identical tables differs . Why ?

2004-05-14 Thread Christopher Kings-Lynne
> I trust in my hardware an O.S so fsync setting is a > big dubt for my production enviroment . Then you are making a big mistake, loving your hardware more than your data... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archiv

R: R: R: [PERFORM] Query plan on identical tables differs . Why ?

2004-05-14 Thread Fabio Panizzutti
>>>-Messaggio originale- >>>Da: [EMAIL PROTECTED] >>>[mailto:[EMAIL PROTECTED] Per conto di >>>Christopher Kings-Lynne >>>Inviato: venerdì 14 maggio 2004 11.55 >>>A: Fabio Panizzutti >>>Cc: 'Manfred Koizar'; [EMAIL PROTECTED] >>>Oggetto: Re: R: R: [PERFORM] Query plan on identical table

[PERFORM] TPCH 100GB - need some help

2004-05-14 Thread Eduardo Almeida
Hi folks, I need some help in a TPCH 100GB benchmark. I described our settings in: http://archives.postgresql.org/pgsql-performance/2004-04/msg00377.php Some queries are taking to long to finish (4, 8, 9, 10, 19,20 and 22) and I need some help to increase the system performance. Here I put the q

Re: [PERFORM] TPCH 100GB - need some help

2004-05-14 Thread Rod Taylor
On Fri, 2004-05-14 at 14:00, Eduardo Almeida wrote: > Hi folks, > > I need some help in a TPCH 100GB benchmark. Performance with 7.5 is much improved over 7.4 for TPCH due to efforts of Tom Lane and OSDL. Give it a try with a recent snapshot of PostgreSQL. Otherwise, disable nested loops for tha

[PERFORM] numeric data types

2004-05-14 Thread Jaime Casanova
Hi all, i have a question, is there any advantages in using numeric(1) or numeric(2) in place of smallint? is there any diff. in performance if i use smallint in place of integer? Thanx in advance, Jaime Casanova _ Help STOP SPAM wi

Re: [PERFORM] numeric data types

2004-05-14 Thread Tom Lane
"Jaime Casanova" <[EMAIL PROTECTED]> writes: > i have a question, is there any advantages in using numeric(1) or numeric(2) > in place of smallint? Performance-wise, smallint is an order of magnitude better. regards, tom lane ---(end of broadcast)

Re: [PERFORM] Quad processor options - summary

2004-05-14 Thread Mark Kirkwood
I would recommend trying out several stripe sizes, and making your own measurements. A while ago I was involved in building a data warehouse system (Oracle, DB2) and after several file and db benchmark exercises we used 256K stripes, as these gave the best overall performance results for both