From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jay Levitt <jay(dot)levitt(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Bugs/slowness inserting and indexing cubes |
Date: | 2012-02-08 19:15:09 |
Message-ID: | 29028.1328728509@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jay Levitt <jay(dot)levitt(at)gmail(dot)com> writes:
> [Posted at Andres's request]
> TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
> various builds.
Not sure yet about most of these, but I know the reason for this one:
> 2. In both 9.1 and 9.2, there is a long delay before CREATE INDEX realizes
> it can't work on an unlogged table
That error is thrown in gistbuildempty, which is not called until after
we have finished building the main-fork index. This is a tad unfriendly
when the table already contains lots of data.
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-02-08 19:23:07 | Re: Bugs/slowness inserting and indexing cubes |
Previous Message | Peter Geoghegan | 2012-02-08 18:48:53 | Re: Progress on fast path sorting, btree index creation time |