From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Marcus Engene <mengpg(at)engene(dot)se> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: bind variables, soft vs hard parse |
Date: | 2005-11-22 20:44:32 |
Message-ID: | 20051122204432.GE99429@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 21, 2005 at 09:14:33PM +0100, Marcus Engene wrote:
> Jim C. Nasby wrote:
> >It might be more useful to look at caching only planning and not
> >parsing. I'm not familiar with the output of the parsing stage, but
> >perhaps that could be hashed to use as a lookup into a cache of planned
> >queries. I suspect that would remove issues of different search_paths.
>
> A really stupid question, in the cached query-string, wouldn't it be
> possible to add the env specifics? Ie the string to check against is
> something like
>
> search_paths=...\n
> SELECT ...
>
> Or would there be too much stuff to append/prepend?
It's probably possible, but the thing is, afaik parsing just isn't a
bottleneck, so it's just not worth messing with that phase. If you do
end up with some super-complex query that does have a non-trivial parse
time, I believe views store a pre-parsed representation of the view
definition (otherwise there'd be issues with changing search_path
between when you create a view and when you use it), so you could
effectively cache something by just stuffing it into a view.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-11-22 20:49:24 | Re: [HACKERS] Should libedit be preferred to libreadline? |
Previous Message | Jim C. Nasby | 2005-11-22 20:38:53 | Re: someone working to add merge? |