Thread: R: R: Query plan on identical tables differs . Why ?

R: R: Query plan on identical tables differs . Why ?

From
"Fabio Panizzutti"
Date:

>>>> 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'::timestamp without
>>>>time
>>>>zone) AND (tag_id = 37423))
>>>
>>>Either most of the time is spent skipping index tuples in
>>>the data_tag range 2004-05-03 to 2004-05-12 which have
>>>tag_id <> 37423, or getting those 835 rows causes a lot of
>>>disk seeks.
>>>
>>>If the former is true, an index on (tag_id, data_tag) will help.
>>>
Is true , i recreate the indexes making an index on  (tag_id, data_tag)
and works fine .


>>>In your first message you wrote:
>>>>fsync = false
>>>
>>>Do this only if you don't care for your data.
>>>

I set it to false , for performance tests .I've a stored procedure that
make about 2000 insert in 2 tables and 2000 delete in another and with
fsync false perfomrmance are  2.000 -3.000 ms (stable) with fsync 3.000
ms to 15.000 ms . I trust in my hardware an O.S so fsync setting is a
big dubt for my production enviroment .

Thanks a lot

Bye


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

From
Christopher Kings-Lynne
Date:
> 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



R: R: R: Query plan on identical tables differs . Why ?

From
"Fabio Panizzutti"
Date:

>>>-----Messaggio originale-----
>>>Da: pgsql-performance-owner@postgresql.org
>>>[mailto:pgsql-performance-owner@postgresql.org] Per conto di
>>>Christopher Kings-Lynne
>>>Inviato: venerdì 14 maggio 2004 11.55
>>>A: Fabio Panizzutti
>>>Cc: 'Manfred Koizar'; pgsql-performance@postgresql.org
>>>Oggetto: Re: R: R: [PERFORM] Query plan on identical tables
>>>differs . Why ?
>>>
>>>
>>>> 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
>>>


I'm testing for better performance in insert/delete so i turn off fsync
, i don't love hardware more than data , so i'll set fsync on in the
production enviroment .
Thanks a lot

Best regards

Fabio