Re: Pre-set Hint bits/VACUUM FREEZE on data load..?

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

In response to

Responses

Browse pgsql-hackers by date

  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