> New TODO entries are:
> 
> 	* Order duplicate index entries by tid

In other words - add tid to index key: very old idea.

> 	* 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? -:)

Vadim

Mon, 30 Jul 2001 10:12:22 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Performance TODO items
> > New TODO entries are:
> > 
> > 	* 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.

> > 	* 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?

Should we be spinning waiting for spinlock on multi-cpu machines?  Is
that the answer?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 30 Jul 2001 13:15:40 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Performance TODO items
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Should we be spinning waiting for spinlock on multi-cpu machines?  Is
> that the answer?

A multi-CPU machine is actually the only case where a true spinlock
*does* make sense.  On a single CPU you might as well yield the CPU
immediately, because you have no chance of getting the lock until the
current holder is allowed to run again.  On a multi CPU it's a
reasonable guess that the current holder is running on one of the other
CPUs and may release the lock soon ("soon" == less than a process
dispatch cycle, hence busy-wait is better than release CPU).

We are currently using spinlocks for a lot of situations where the mean
time spent holding the lock is probably larger than "soon" as defined
above.  We should have a different lock implementation for those cases.
True spinlocks should be reserved for protecting code where the maximum
time spent holding the lock is guaranteed to be very short.

			regards, tom lane

Mon, 30 Jul 2001 15:29:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Performance TODO items 