Re: Why could different data in a table be processed with different performance? - Mailing list pgsql-performance

From Vladimir Ryabtsev
Subject Re: Why could different data in a table be processed with different performance?
Date
Msg-id CAMqTPqnOJbdjca9cPcLr2R7XttJSPqVN4bnTJcjy2Pjt9uX27Q@mail.gmail.com
Whole thread Raw
In response to Re: Why could different data in a table be processed with differentperformance?  (Fabio Pardi <f.pardi@portavita.eu>)
Responses Re: Why could different data in a table be processed with differentperformance?  (Fabio Pardi <f.pardi@portavita.eu>)
List pgsql-performance
> Since you have a very big toast table, given you are using spinning disks, I think that increasing the block size will bring benefits.
But will it worsen caching? I will have lesser slots in cache. Also will it affect required storage space?

>> consecutive runs with SAME parameters do NOT hit the disk, only the first one does, consequent ones read only from buffer cache.
> I m  a bit confused.. every query you pasted contains 'read':
>        Buffers: shared hit=50 read=2378
> and 'read' means you are reading from disk (or OS cache). Or not? 
Yes, sorry, it was just my misunderstanding of what is "consecutive". To make it clear: I iterate over all data in table with one request and different parameters on each iteration (e.g. + 5000 both borders), in this case I get disk reads on each query run (much more reads on "slow" range). But if I request data from an area queried previously, it reads from cache and does not hit disk (both ranges). E.g. iterating over 1M of records with empty cache takes ~11 minutes in "fast" range and ~1 hour in "slow" range, while on second time it takes only ~2 minutes for both ranges (if I don't do drop_caches).

Regards,
Vlad

pgsql-performance by date:

Previous
From: David Rowley
Date:
Subject: Re: To keep indexes in memory, is large enough effective_cache_size enough?
Next
From: Justin Pryzby
Date:
Subject: reference regarding write load during different stages of checkpoint