Gregory Stark wrote: > "Bruce Momjian" <[EMAIL PROTECTED]> writes: > > > Matthew T. O'Connor wrote: > >> Bruce Momjian wrote: > >> > > >> > * Allow multiple indexes to be created concurrently, ideally via a > >> > single heap scan, and have a restore of a pg_dump somehow use it > > Actually, the sync scan patch ought to make this more or less happen > magically. If you start a bunch of concurrent index builds they will try to > scan the table together. > > There's no useful way for pg_dump to make use of this since it only has one > backend. And you still need to generate n copies of the data for sorting. And > performing n sorts in parallel won't be as cache efficient as doing them one > after the other. So there's still a use case for the TODO > > But the hole is not nearly as urgent as before. You can get most of the > benefit if you really need it by rolling your own. And the cool thing is some > people already have rolled their own and they'll just magically see an > improvement. They don't have to do anything they weren't doing already to turn > it on.
They could roll their own a lot easier if you had finished the psql concurrent patch. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
