Re: cache in plpgsql

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: cache in plpgsql
Дата
Msg-id 3FF4DC86.1000400@Yahoo.com
обсуждение исходный текст
Ответ на Re: cache in plpgsql  (ivan <iv@psycho.pl>)
Ответы Re: cache in plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
ivan wrote:

>may be postgres can use same way like triggers working,
>and when relation is droping ( what is equal to delete from pg_class)
>there could be something like trigger after .. which can
>waiting for CREATE or DROP command, and then clean-up cache,
>(for each backend).
>This could be for example same message, not just trigger
>(i said trigger only to show scheme of acction)
>
>ehheh this idea is also wrong ?
>

Ivan,

I really appreciate that you are thinking about this problem. But you 
keep talking about it as if this would be some sort of shared buffer 
cache. Do you know what a saved SPI execution plan is?

Your idea is neither bad nor new, there actually is a so called system 
cache invalidation event propagated to every backend in the case of 
catalog changes, so that it can purge it's syscache. But can you tell me 
how to actually check if a saved SPI plan references that particular 
catalog object or not?


Jan

>
>On Wed, 31 Dec 2003, Jan Wieck wrote:
>
>  
>
>>ivan wrote:
>>    
>>
>>>why all backend can not using one cache, which would be always
>>>      
>>>
>>Variable sized shared memory with garbage collection for SPI plans?
>>
>>    
>>
>>>in real state ... or i can just clear only my cache, at first
>>>(if i know that this relation could has another oid)
>>>and then normal using relations ?
>>>      
>>>
>>As said, that is not sufficient. The user who does the DDL statement can
>>as well reconnect to the database to recompile all saved plans. It is
>>the 200 persistent PHP DB connections that suffer from not finding the
>>index any more.
>>
>>    
>>
>>>or ... just turn off cache, because its strange to has possible
>>>using drop, create etc in function, but using only EXECUTE ..
>>>      
>>>
>>Do you have any numbers about how that would affect performance?
>>
>>
>>Jan
>>
>>    
>>
>>>there must be same solution .. no ?
>>>
>>>
>>>On Wed, 31 Dec 2003, Jan Wieck wrote:
>>>
>>>      
>>>
>>>>ivan wrote:
>>>>
>>>>        
>>>>
>>>>>as new know plpgsql has special cache which remember too long (event
>>>>>non-existing tables (i mean old oid)) so i suggest to create same function
>>>>>only in plpgsql which would clear this cache, or sth like this ?
>>>>>
>>>>>for ie, where i drop table i would do plpgsql_clear_cache ();
>>>>>and when i will create one more time table with this same name plpgsql
>>>>>will not remeber wrong oid
>>>>>
>>>>>possible ?
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>You obviously did not bother to search the archives on this.
>>>>
>>>>This will not solve the problem since the "cache" you're talking about
>>>>is per backend local memory. So if one backend modifies the schema, how
>>>>does it cause all other to forgt? Since the same problem exists in
>>>>general for everything that uses SPI, the solution lies in there.
>>>>
>>>>
>>>>Jan
>>>>
>>>>--
>>>>
>>>>#======================================================================#
>>>># It's easier to get forgiveness for being wrong than for being right. #
>>>># Let's break this rule - forgive me.                                  #
>>>>#================================================== JanWieck@Yahoo.com #
>>>>
>>>>
>>>>
>>>>
>>>>---------------------------(end of broadcast)---------------------------
>>>>TIP 3: if posting/reading through Usenet, please send an appropriate
>>>>      subscribe-nomail command to majordomo@postgresql.org so that your
>>>>      message can get through to the mailing list cleanly
>>>>
>>>>        
>>>>
>>--
>>#======================================================================#
>># It's easier to get forgiveness for being wrong than for being right. #
>># Let's break this rule - forgive me.                                  #
>>#================================================== JanWieck@Yahoo.com #
>>
>>    
>>


-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Manfred Spraul
Дата:
Сообщение: Re: using stp for dbt2 + postgresql
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Spinlock support for linux-hppa?