Re: Bugs/slowness inserting and indexing cubes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bugs/slowness inserting and indexing cubes
Дата
Msg-id 29291.1328729917@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Bugs/slowness inserting and indexing cubes  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Bugs/slowness inserting and indexing cubes  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Bugs/slowness inserting and indexing cubes
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Progress on fast path sorting, btree index creation time