Re: iscacheable for date/time?
От | mlw |
---|---|
Тема | Re: iscacheable for date/time? |
Дата | |
Msg-id | 3BB1DFB6.CEB6CE8E@mohawksoft.com обсуждение исходный текст |
Ответ на | iscacheable for date/time? (Thomas Lockhart <lockhart@fourpalms.org>) |
Список | pgsql-hackers |
Thomas Lockhart wrote: > ... and how about the istrusted attribute for various routines? Should > it be always false or always true for C builtin functions? How about for > builtin SQL functions which are built on top of trusted C functions? Are > we guarding against catalog changes on the underlying C routines? I have always had trouble with the "iscacheable" flag, there needs to be a number of "cache" levels: (1) cache per transaction, so you can use a function in a where statement and it does not force a table scan. IMHO this should be the default for all functions, but is not supported in PostgreSQL. (2) nocache, which would mean it forces a tables scan. This is the current default. (3) global cache, which means the results can be stored in perpetuity, this is the current intended meaning of iscacheable.
В списке pgsql-hackers по дате отправления: