Skip site navigation (1) Skip section navigation (2)

RE: Performance TODO items

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: Performance TODO items
Date: 2001-07-30 17:45:30
Message-ID: 3705826352029646A3E91C53F7189E320166FA@sectorbase2.sectorbase.com (view raw or flat)
Thread:
Lists: 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

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-07-30 17:58:15
Subject: Re: Performance TODO items
Previous:From: Bill StudenmundDate: 2001-07-30 17:37:16
Subject: Re: SIGCHLD handler in Postgres C function.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group