From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Pre-set Hint bits/VACUUM FREEZE on data load..? |
Date: | 2011-03-25 07:51:43 |
Message-ID: | 4D8C498F.2000708@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 24.03.2011 23:54, Stephen Frost wrote:
> * Heikki Linnakangas (heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Farina | 2011-03-25 07:57:03 | Re: Avoiding timeline generation |
Previous Message | Heikki Linnakangas | 2011-03-25 07:38:42 | Re: Avoiding timeline generation |