Re: Pre-set Hint bits/VACUUM FREEZE on data load..?
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Pre-set Hint bits/VACUUM FREEZE on data load..? |
| Дата | |
| Msg-id | 4D8C498F.2000708@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: Pre-set Hint bits/VACUUM FREEZE on data load..? (Stephen Frost <sfrost@snowman.net>) |
| Ответы |
Re: Pre-set Hint bits/VACUUM FREEZE on data load..?
|
| Список | pgsql-hackers |
On 24.03.2011 23:54, Stephen Frost wrote: > * Heikki Linnakangas (heikki.linnakangas@enterprisedb.com) wrote: >> The problem is that you still need to track which queries within the >> transaction can see the tuples. For example: > > Wow, that's a good point wrt cursors. Sounds more and more like we'd > need a special data-loading mode for this where we'd have to disallow > those options. I've been thinking that's a frowned-upon approach in > general, but let me ask specifically- are we uninterested in such a > special 'data-load' mode? Or do we expect that the limitations would be > too great to make it useful enough for users? That last I don't think I > agree with.. I don't think we should put the onus on the user to choose the right data loading mode. If we can reliably detect the cases where it's safe do these tricks, we can transparently apply them when possible. I would be cool with tricks that apply only in narrow cases, as long as we don't require the user to do anything. That said, it can be surprising if some trivial change to the schema happens to disable the optimization, and your query performance after data load suddenly plummets. That can be a pain for the DBA to debug. I'm skeptical of changes that need any extra checks in the fast-path of HeapTupleSatisfiesMVCC. That is a hot spot already, any extra cycles there would add up to hurt performance. Careful performance testing is required. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: