On 24.03.2011 23:54, Stephen Frost wrote:
* Heikki Linnakangas (heikki.linnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
