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
On Wed, Nov 16, 2005 at 10:19:21AM +0100, Marcus Engene wrote:
> Martijn van Oosterhout wrote:
> >>This sql cache I think is a really good thing. Is there a reason
> >>Postgres hasn't got it? Would it be very hard to implement? From
> >>a naive perspective; make a hashvalue from the sql-string to
>
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.
Martijn van Oosterhout writes:
> Unless you use something like pgpool, in which case a single session
> may include multiple requests.
Actually, I've found pgpool to be no better when it comes to using
real prepared queries---there's no guarantee that any given request is
going to connect to the
Martijn van Oosterhout wrote:
But this is of no use in a web-context. According to the docs, this
prepare is per session.
Unless you use something like pgpool, in which case a single session
may include multiple requests.
ok. Good point.
This sql cache I think is a really good thing. Is the
Christopher Kings-Lynne wrote:
> Oracle recently gave some money to Zend to make proper Oracle
support
> for PHP. In that interface they use bind variables. Apart from
greater
> speed, sqlinjection becomes history as well.
I did the same for PostgreSQL for PHP 5.1.
http://
On Wed, Nov 16, 2005 at 09:56:44AM +0100, Marcus Engene wrote:
> Douglas McNaught wrote:
> >You can do this (or close to it) but you need to explicitly PREPARE
> >the query (or use the protocol-level prepare, which some client
> >libraries will do for you). See the SQL documentation for PREPARE.
>
Douglas McNaught wrote:
Which will be the same as the second call. There is quite a big
difference in performance using bind variables.
Does Postgres work the same? Where can I go for more info?
You can do this (or close to it) but you need to explicitly PREPARE
the query (or use the protocol-
> Oracle recently gave some money to Zend to make proper Oracle support
> for PHP. In that interface they use bind variables. Apart from
greater
> speed, sqlinjection becomes history as well.
I did the same for PostgreSQL for PHP 5.1.
http://au3.php.net/manual/en/function.pg-
In some cases, Oracle will also replace literals with bind variables so that it can perform a sort-of-bind-value soft parse later.
On 11/15/05, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
PostgreSQL combines both parses into one, so every new query iseffectively a hard parse (unless it's prepared, th
PostgreSQL combines both parses into one, so every new query is
effectively a hard parse (unless it's prepared, then there is no parse
or optimization at all).
On Tue, Nov 15, 2005 at 07:33:46PM +0100, Marcus Engene wrote:
> Hi list.
>
> I've mostly used Oracle in the past, but for a web-project
Marcus Engene <[EMAIL PROTECTED]> writes:
> Which will be the same as the second call. There is quite a big
> difference in performance using bind variables.
>
> Does Postgres work the same? Where can I go for more info?
You can do this (or close to it) but you need to explicitly PREPARE
the quer
Hi list.
I've mostly used Oracle in the past, but for a web-project I took the
opportunity to try Postgres.
When a select is done in Oracle, it first checks if the select is cached
(ie parsed tree, optimizer choices & such). It does this by
[functionality equal to] a byte to byte compare wit
13 matches
Mail list logo
