On Fri, Oct 19, 2012 at 11:40 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Hitoshi Harada <umi.tan...@gmail.com> writes: >> On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I'm not terribly comfortable with trying to use a PG_TRY block to catch >>> an OOM error - there are too many ways that could break, and this code >>> path is by definition not very testable. I think moving up the >>> expand_table action is probably the best bet. Will you submit a patch? > >> Here it is. I factored out the bucket finding code to re-calculate it >> after expansion. > > I didn't like that too much. I think a better solution is just to do > the table expansion at the very start of the function, along the lines > of the attached patch. This requires an extra test of the "action" > parameter, but I think that's probably cheaper than an extra function > call. It's definitely cheaper than recalculating the hash etc when > a split does occur. >
OK. Looks better. But nentries should be bogus a little now? + /* + * Can't split if running in partitioned mode, nor if frozen, nor if + * table is the subject of any active hash_seq_search scans. Strange + * order of these tests is to try to check cheaper conditions first. + */ + if (!IS_PARTITIONED(hctl) && !hashp->frozen && + hctl->nentries / (long) (hctl->max_bucket + 1) >= hctl->ffactor && + !has_seq_scans(hashp)) + (void) expand_table(hashp); hctl->nentries + 1 sounds appropriate? Thanks, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
