pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Qingqing Zhou <zhouqq@cs.toronto.edu>
To: pgsql-performance@postgresql.org
Subject: Re: Help in avoiding a query 'Warm-Up' period/shared buffer cache
Date: Thu, 5 Jan 2006 18:12:13 -0500
Message-ID: <dpk922$slo$1@news.hub.org> (raw)
References: <200601041449.43557.mliberman@mixedsignals.com>


"Mark Liberman" <mliberman@mixedsignals.com> wrote
>
> First run, after a night of inactivity:
>
>                     ->  Bitmap Index Scan on 1min_events_file_id_begin_idx
> (cost=0.00..37.85 rows=3670 width=0) (actual time=313.468..313.468 
> rows=11082
> loops=1)
>                           Index Cond: (file_id = 137271)
> Total runtime: 313.643 ms
>
> Second run, after that:
>
>                     ->  Bitmap Index Scan on 1min_events_file_id_begin_idx
> (cost=0.00..37.85 rows=3670 width=0) (actual time=2.106..2.106 rows=11082
> loops=1)
>                           Index Cond: (file_id = 137271)
> Total runtime: 2.276 ms

It is clear that the first query takes longer time because of the IO time of 
index 1min_events_file_id_begin_idx (see 313.468 vs. 2.106). I am afraid 
currently there is no easy solution for this situation, unless you could 
predicate which part of relation/index your query will use, then you can 
preload or "warm-up" cache for it.

Regards,
Qingqing






view thread (6+ messages)  latest in thread

Message-ID: <dpk922$slo$1@news.hub.org>
Permalink:  ../dpk922$slo$1@news.hub.org/
Also on:    postgresql.org/message-id/dpk922$slo$1@news.hub.org

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: zhouqq@cs.toronto.edu
  Subject: Re: Help in avoiding a query 'Warm-Up' period/shared buffer cache
  In-Reply-To: <dpk922$slo$1@news.hub.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox