Re: Bugs/slowness inserting and indexing cubes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jay Levitt <jay(dot)levitt(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bugs/slowness inserting and indexing cubes
Date: 2012-02-08 19:38:37
Message-ID: 29291.1328729917@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ISTM there are two ways we could fix this:
>>
>> 1. Introduce a duplicative test at the start of gistbuild().
>>
>> 2. Rearrange the order of operations in index_build() so that the init
>> fork is made first.
>>
>> Both of these are kinda ugly, but #2 puts the ugliness into someplace
>> that shouldn't have to know about it, and furthermore someplace that's
>> unlikely to get reverted if/when gist is fixed to not have this problem.
>> So I think I favor #1. Other opinions anyone?

> I don't think I understand your object to #2. It appears to be a
> trivial rearrangement?

Yeah, but then we are wiring into index_build the idea that ambuildempty
is more important, or more likely to throw an error, or something, than
ambuild is. It seems weird. And fragile, since somebody could decide
to re-order those two steps again for reasons unrelated to gist.
Basically, I think this problem is gist's to deal with and so that's
where the fix should be.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2012-02-08 19:50:18 Re: Progress on fast path sorting, btree index creation time
Previous Message Robert Haas 2012-02-08 19:23:07 Re: Bugs/slowness inserting and indexing cubes