RE: Performance TODO items
От | Mikheev, Vadim |
---|---|
Тема | RE: Performance TODO items |
Дата | |
Msg-id | 3705826352029646A3E91C53F7189E320166FA@sectorbase2.sectorbase.com обсуждение исходный текст |
Ответ на | Performance TODO items (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Performance TODO items
|
Список | pgsql-hackers |
> > > * Order duplicate index entries by tid > > > > In other words - add tid to index key: very old idea. > > I was thinking during index creation, it would be nice to > order them by tid, but not do lots of work to keep it that way. I hear this "not do lots of work" so often from you -:) Days of simplicity are gone, Bruce. To continue, this project requires more and more complex solutions. > > > * Add queue of backends waiting for spinlock > > > > We shouldn't mix two different approaches for different > > kinds of short-time internal locks - in one cases we need in > > light lmgr (when we're going to keep lock long enough, eg for IO) > > and in another cases we'd better to proceed with POSIX' mutex-es > > or semaphores instead of spinlocks. Queueing backends waiting > > for spinlock sounds like nonsense - how are you going to protect > > such queue? With spinlocks? -:) > > Yes, I guess so but hopefully we can spin waiting for the queue lock > rather than sleep. We could use POSIX spinlocks/semaphores now but we > don't because of performance, right? No. As long as no one proved with test that mutexes are bad for performance... Funny, such test would require ~ 1 day of work. > Should we be spinning waiting for spinlock on multi-cpu machines? Is > that the answer? What do you mean? Vadim
В списке pgsql-hackers по дате отправления: