Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] Interesting incosistent query timing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ernest E Vogelsinger <ernest(at)vogelsinger(dot)at>
Cc: nikolaus(at)dilger(dot)cc, pgsql-performance(at)postgresql(dot)org,pgsql-general(at)postgresql(dot)org
Subject: Re: [PERFORM] Interesting incosistent query timing
Date: 2003-06-18 00:12:18
Message-ID: 17950.1055895138@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-performance
Ernest E Vogelsinger <ernest(at)vogelsinger(dot)at> writes:
> I came to the same conclusion - I installed a cron script that performs a
> select against that index on a regular basis (3 minutes). After that even
> the most complex queries against this huge table go like whoosssshhh ;-)
> Would be interesting what one could do to _not_ have to take this basically
> clumsy approach...

Seems like your kernel is falling down on the job: if those files are
the most heavily used ones on the machine, it should be keeping them in
disk cache without such prompting.

If they are not all that heavily used, then you are basically slowing
everything else down in order to speed up these queries (because you're
starving everything else for disk cache).  Which may be a reasonable
tradeoff in your situation, but be aware of what you're doing.

The best compromise may be to buy more RAM ;-)

			regards, tom lane

In response to

pgsql-performance by date

Next:From: SZŰCS GáborDate: 2003-06-18 07:11:25
Subject: Re: Postgres Connections Requiring Large Amounts of Memory
Previous:From: Tom LaneDate: 2003-06-17 23:21:41
Subject: Re: Postgres Connections Requiring Large Amounts of Memory

pgsql-general by date

Next:From: Tom LaneDate: 2003-06-18 00:13:24
Subject: Re: EFFECTIVE_CACHE_SIZE
Previous:From: Tom LaneDate: 2003-06-18 00:08:29
Subject: Re: Sort memory not being released

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group