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 > >>quickly find the cached one, a "last used"-list for keeping > >>track of which to delete when cache full etc seems close to > >>trivial. Does the architecture/internal flow make it hard > >>actually reuse the query data structure? > > > >It's hard to reuse the structure. Also, things like search_path mean > >that the same query text can mean completely different things in > >different backends. Most of the time it's planning that dominates, not > >parsing so storing just the parser output seems somewhat useless. > > Of course I didn't mean only the parse was to be saved. The planning > goes there too.
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. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
