Query caching 
Author Message
 Query caching

Quote:



> > > > What about parameters? Normally you can prepare a statement and execute it

> > >  We have in PG parameters, see SPI, but now it's used inside backend only
> > > and not exist statement that allows to use this feature in be<->fe.

> > Sad. Since ecpg would certainly benefit from this.

Postponed for future improvements ...

Quote:
> > > PREPARE chris_query AS SELECT * FROM pg_class WHERE relname = $1 USING text;

> > I would prefer '?' as a parameter name, since this is in the embedded sql standard
> > (do you have a copy of the 94 draft? I can mail mine to you?)

>  This not depend on query cache. The '$n' is PostgreSQL query parametr
> keyword and is defined in standard parser. The PREPARE statement not parsing
> query it's job for standard parser.

I see.

Quote:
> > Also the standard says a whole lot about guessing the parameter's type.

> > Also I vote for  ?::type or type(?) or sql's cast(...) (don't know it's syntax)
> > instead of abusing the using keyword.

> The postgresql executor expect types of parametrs in separate input (array).
> I not sure how much expensive/executable is survey it from query.

That would involve changing the parser. Future project.

Quote:
> > > EXECUTE chris_query USING 'pg_shadow';

> > Great idea of yours to implement this! Since I was thinking about implementing a
> > more decent schema for ecpg but had no mind to touch the backend and be-fe
> > protocol (yet).
> > It would be desirable to do an 'execute immediate using', since using input
> > parameters would take a lot of code away from ecpg.

> By the way, PREPARE/EXECUTE is face only. More interesting in this period is
> query-cache-kernel. SQL92 is really a little unlike my PREPARE/EXECUTE.

I'm looking forward to get first experiences with the query cache kernel. I think it's
the right way to go.

Christof



Tue, 29 Apr 2003 15:57:36 GMT
 Query caching

Did someone think about query costs ? Is you prepare
query like SELECT id FROM t1 WHERE type=$1 and
execute it with $1=1 and 2. For 1 there is one record
in t1 a all other have type=2.
Without caching, first query will use index, second
not.
Should cached plan use index or not ?
devik
Quote:




> > > > > What about parameters? Normally you can prepare a statement and execute it

> > > >  We have in PG parameters, see SPI, but now it's used inside backend only
> > > > and not exist statement that allows to use this feature in be<->fe.

> > > Sad. Since ecpg would certainly benefit from this.

> Postponed for future improvements ...

> > > > PREPARE chris_query AS SELECT * FROM pg_class WHERE relname = $1 USING text;

> > > I would prefer '?' as a parameter name, since this is in the embedded sql standard
> > > (do you have a copy of the 94 draft? I can mail mine to you?)

> >  This not depend on query cache. The '$n' is PostgreSQL query parametr
> > keyword and is defined in standard parser. The PREPARE statement not parsing
> > query it's job for standard parser.

> I see.

> > > Also the standard says a whole lot about guessing the parameter's type.

> > > Also I vote for  ?::type or type(?) or sql's cast(...) (don't know it's syntax)
> > > instead of abusing the using keyword.

> > The postgresql executor expect types of parametrs in separate input (array).
> > I not sure how much expensive/executable is survey it from query.

> That would involve changing the parser. Future project.

> > > > EXECUTE chris_query USING 'pg_shadow';

> > > Great idea of yours to implement this! Since I was thinking about implementing a
> > > more decent schema for ecpg but had no mind to touch the backend and be-fe
> > > protocol (yet).
> > > It would be desirable to do an 'execute immediate using', since using input
> > > parameters would take a lot of code away from ecpg.

> > By the way, PREPARE/EXECUTE is face only. More interesting in this period is
> > query-cache-kernel. SQL92 is really a little unlike my PREPARE/EXECUTE.

> I'm looking forward to get first experiences with the query cache kernel. I think it's
> the right way to go.

> Christof



Wed, 30 Apr 2003 00:34:33 GMT
 
 [ 2 post ] 

 Relevant Pages 

1. Flushing the query cache

2. Query Cache

3. Why is MS Query caching the results?

4. query cache

5. Query caching

6. ad-hoc query caching in SQL2K

7. mysql query cached - how to force?

8. My only post with regard to query caching

9. [GENERAL] Query caching

10. Unix Cache vs Ingres DMF Cache

11. one large cache or many named caches?


 
Powered by phpBB® Forum Software