On Jul 15, 2009, at 2:52 PM, Dimitri Fontaine wrote:
Le 15 juil. 09 à 02:01, Glen Parker a écrit :
Sounds to me like another reason to separate index definition from
creation. If an index can be defined but not yet created or
valid, then you could imagine syntax like:
DEFINE INDEX
decibel wrote:
Here's an off-the-wall thought... since most of the CPU time is in the
sort, what about allowing a backend to fork off dedicated sort
processes? Aside from building multiple indexes at once, that
functionality could also be useful in general queries.
Sure, that would be cool.
Andrew Dunstan wrote:
Wasn't that a big part of the point of the parallel pg_restore feature?
Well, yes, it's some of it, and in theory Tom's late addition of a queue
that gets all the dependencies of a table as soon as the table data is
restored should make that work better. But
Bruce Momjian br...@momjian.us writes:
Well, TODO has:
Allow multiple indexes to be created concurrently, ideally via a
single heap scan, and have pg_restore use it
Isn't this already largely done by parallel pg_restore work?
so we have to decide if we still want
Hi,
Le 15 juil. 09 à 02:01, Glen Parker a écrit :
Sounds to me like another reason to separate index definition from
creation. If an index can be defined but not yet created or valid,
then you could imagine syntax like:
DEFINE INDEX blahblah1 ON mytable (some fields);
DEFINE INDEX
I was just wondering idly today if we could usefully build a number of
indexes at the same time in a single pass over the heap, or could it be
that we wouldn't gain much? I haven't even got around to thinking about
any syntax for it.
cheers
andrew
--
Sent via pgsql-hackers mailing list
Andrew Dunstan wrote:
I was just wondering idly today if we could usefully build a number of
indexes at the same time in a single pass over the heap, or could it be
that we wouldn't gain much? I haven't even got around to thinking about
any syntax for it.
Could we make it work on two
Alvaro Herrera alvhe...@commandprompt.com writes:
Andrew Dunstan wrote:
I was just wondering idly today if we could usefully build a number of
indexes at the same time in a single pass over the heap, or could it be
that we wouldn't gain much? I haven't even got around to thinking about
On Tue, Jul 14, 2009 at 8:50 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Andrew Dunstan wrote:
I was just wondering idly today if we could usefully build a number of
indexes at the same time in a single pass over the heap, or could it be
that we
Greg Stark wrote:
On Tue, Jul 14, 2009 at 8:50 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Andrew Dunstan wrote:
I was just wondering idly today if we could usefully build a number of
indexes at the same time in a single pass over
Andrew Dunstan wrote:
Well, yes, it's some of it, and in theory Tom's late addition of a queue
that gets all the dependencies of a table as soon as the table data is
restored should make that work better. But of course, that's not the
only time indexes are created, and each index creation
11 matches
Mail list logo
