Tom Lane wrote:
> I wrote:
>> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>>> We could have two kinds of seq scans, with and without support for
>>> concurrent inserts.
>> Yeah, I considered that too, but it just seems too error-prone. We
>> could maybe make it trustworthy by having hash_seq_search complain if
>> it noticed there had been any concurrent insertions --- but then you're
>> putting new overhead into hash_seq_search, which kind of defeats the
>> argument for it (and hash_seq_search is a bit of a bottleneck, so extra
>> cycles there matter).
> I just finished looking through the uses of hash_seq_search, and
> realized that there is one place where it would be a bit painful to
> convert to the insertion-safe approach I'm proposing; namely nodeAgg.c.
> The places where the hashtable iteration is started and used are
> scattered, and we don't really track whether the iteration is done or
> not, so it's hard to be sure where to cancel the iteration. It could
> probably be made to work but it seems like it'd be fragile.
> I still don't want to introduce more checking overhead into
> hash_seq_search, though, so what I'm now thinking about is a new
> dynahash primitive named something like "hash_freeze", which'd mark a
> hashtable as disallowing insertions. If the hashtable is frozen before
> hash_seq_init then we don't add it to the central list of scans, and
> therefore there is no cleanup to do at the end. nodeAgg can use this
> mode since it doesn't modify its hashtable anymore after beginning its
> readout scan.
This plan includes having the list of hash tables that mustn't be
expanded? And the list would be cleaned up at the end of transaction, to
> BTW, we didn't really get into details, but for the insertion-safe case
> I'm envisioning adding a routine "hash_seq_term", which you would need
> to call if and only if you abandon a hash_seq_search scan without
> running it to completion (if you do the complete scan, hash_seq_search
> will automatically call hash_seq_term before returning NULL). All but
> a very small number of places run their searches to completion and
> therefore won't require any source code changes with this API.
Sounds good to me.
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2007-04-25 21:44:25|
|Subject: Re: Avoiding unnecessary reads in recovery|
|Previous:||From: Tom Lane||Date: 2007-04-25 21:08:49|
|Subject: Re: Vacuum-full very slow |
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2007-04-25 21:46:47|
|Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect |
|Previous:||From: Jeff Davis||Date: 2007-04-25 20:57:09|
|Subject: Re: pg_dump doesn't properly honor -O for sequences|
pgsql-patches by date
|Next:||From: Magnus Hagander||Date: 2007-04-25 21:31:20|
|Subject: Re: Fix for MSVC header installation|
|Previous:||From: Tom Lane||Date: 2007-04-25 20:56:46|
|Subject: Re: Fix for MSVC header installation |