Re: Progress on fast path sorting, btree index creation time
| От | Peter Geoghegan |
|---|---|
| Тема | Re: Progress on fast path sorting, btree index creation time |
| Дата | |
| Msg-id | CAEYLb_XQF6guOVgtR=4u7oTPWZGpr6GpD7AgUOofE1b6ixM+eA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Progress on fast path sorting, btree index creation time (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
On 15 February 2012 15:27, Robert Haas <robertmhaas@gmail.com> wrote: >> I am inclined to agree that given that we already use Perl to generate >> source code like this, it seems natural that we should prefer to do >> that, if only to avoid paranoia about the inclusion of a dial-a-bloat >> knob. I am at a disadvantage here, since I've never written a line of >> Perl. > > I think it's still dial-a-bloat, but I feel pretty comfortable about > how we've got that knob adjusted in this version. It's almost as much > improvement as any previous version, it applies to more cases, and the > code footprint is the least of any version I've measured. I'm happy that the principle that a dial-a-bloat knob isn't necessarily a bad thing has been accepted, though that term is kind of pejorative in that it implies that the knob necessarily adds bloat to the binary. I define bloat here as the addition of dead instructions to the binary, or at least code that doesn't pull its weight. Clearly, that isn't the case here, and I suspect that we will find that it isn't the case in other places too. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: