| From: | Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: please help understand freeing shared buffers |
| Date: | 2012-01-06 21:45:35 |
| Message-ID: | CAP_rwwnBUvU=FcBfxMO5zRLbkZTa3gy47=84vhXgt=h1hTiz9g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
2012/1/6 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> =?UTF-8?Q?Filip_Rembia=C5=82kowski?= <filip(dot)rembialkowski(at)gmail(dot)com> writes:
>> Among following queries, only THREE runs fast enough for me.
>> I can't understand the logic behind this.
>
> I'm not sure why you'd expect real answers when you haven't shown us
> what the query is doing,
it is an UDF, encapsulating a single SELECT where a=$1 and b=$2 and c=$3
> but my first thought is that the discrepancy
> comes from additional buffer touches in the first execution of a query
> in a given backend; which is not exactly surprising because that backend
> has to load up its system catalog caches. IOW, the excess touches
> represent accesses to system catalogs not user tables.
>
> In general, if you're annoyed by query execution times measured in
> milliseconds, you'd be best advised not to start a fresh connection
> for each one. A new connection not only involves a process launch
> but a fair amount of loading of local caches, and a large part of
> the latter work happens during the first few queries it processes.
thank you, that explains a lot.
I misinterpreted the number of buffer hits as true buffer reads.
sure, using persistent connections is what I will do (we have pgbouncer here)
Filip
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lee Hachadoorian | 2012-01-06 21:56:17 | Re: JOIN column maximum |
| Previous Message | Steve Crawford | 2012-01-06 21:24:52 | Re: URGENT: temporary table not recognized? |