Re: Performance on inserts
От | Jules Bean |
---|---|
Тема | Re: Performance on inserts |
Дата | |
Msg-id | 20000831124042.I24680@grommit.office.vi.net обсуждение исходный текст |
Ответ на | Re: Performance on inserts (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, Aug 26, 2000 at 05:09:53PM -0400, Tom Lane wrote: > Tom Lane <tgl@sss.pgh.pa.us> writes: > > Jules Bean <jules@jellybean.co.uk> writes: > >> Is there any chance you could generate a patch against released 7.0.2 > >> to add just this functionality... It would be the kiss of life for my > >> code! > > > Will look at it. > > I looked at it and decided that I don't want to mess with it. The > BTP_CHAIN logic in 7.0 is so weird and fragile that it's hard to tell > what will happen if we try to split anything but the last page of a > chain of duplicates. The idea I'd had of just dropping in the whole > btree module from current sources doesn't look very practical either; > a lot of changes that span module boundaries would have to be backed out > of it. > > My recommendation is to try out current sources (from a nightly snapshot > or CVS). I realize that running a non-released version might make you > uncomfortable, and rightly so; but I believe that current sources are in > pretty good shape right now. In any case, working out any bugs lurking > in current strikes me as a much more profitable activity than trying to > back-patch the old btree code. OK. Thanks very much for going through this with me. I'm actually going to simply do without the index for this release of my software -- it's an internal project, and the speed problems of having no index aren't disastrous. However, I'd rather not fight any instabilities, this project runs long-term and mostly unattended. I'll certainly keenly upgrade to 7.1 when it comes out, though, with the new btree logic. Jules
В списке pgsql-hackers по дате отправления: