| От | Rod Taylor |
|---|---|
| Тема | Re: Performance Anomalies in 7.4.5 |
| Дата | |
| Msg-id | 1098984056.8557.637.camel@home обсуждение исходный текст |
| Ответ на | Re: Performance Anomalies in 7.4.5 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Performance Anomalies in 7.4.5
|
| Список | pgsql-performance |
On Thu, 2004-10-28 at 12:31, Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: > >> One drawback to this is that it would require an additional lseek per table > >> while planning, but that doesn't seem like a huge penalty. > > > Hmmm ... would the additional lseek take longer for larger tables, or would it > > be a fixed cost? > > Should be pretty much a fixed cost: one kernel call per table. Is this something that the bgwriter could periodically do and share the data? Possibly in the future it could even force a function or prepared statement recompile if the data has changed significantly?
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера