| From: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Help in avoiding a query 'Warm-Up' period/shared buffer cache |
| Date: | 2006-01-05 23:12:13 |
| Message-ID: | dpk922$slo$1@news.hub.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Mark Liberman" <mliberman(at)mixedsignals(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Patrick Hatcher | 2006-01-06 00:38:17 | Slow query. Any way to speed up? |
| Previous Message | Frank Wiles | 2006-01-05 19:20:06 | Re: Improving Inner Join Performance |