> > > > 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.
> >
> > Good question. I know the number
> On Mon, 30 Jul 2001, Bruce Momjian wrote:
>
> > * Improve spinlock code, perhaps with OS semaphores, sleeper queue, or
> > spining to obtain lock on multi-cpu systems
>
> You may be interested in a discussion which happened over on
> linux-kernel a few months ago.
>
> Quite a lot of people
On Mon, 30 Jul 2001, Bruce Momjian wrote:
> * Improve spinlock code, perhaps with OS semaphores, sleeper queue, or
> spining to obtain lock on multi-cpu systems
You may be interested in a discussion which happened over on
linux-kernel a few months ago.
Quite a lot of people want a lightweight
> A more general solution is for indexscan to collect up a bunch of TIDs
> from the index, sort them in-memory by TID order, and then probe into
> the heap with those TIDs. This is better than the above because you get
> nice ordering of the heap accesses across multiple key values, not just
> am
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have thought of a few new TODO performance items:
> 1) Someone at O'Reilly suggested that we order our duplicate index
> entries by tid so if we are hitting the heap for lots of duplicates, the
> hits will be on sequential pages. Seems like a nice id
> So why do we cache sequetially-read pages? Or at least not have an
> option to control it?
>
> Oracle (to the best of my knowledge) does NOT cache pages read by a
> sequential index scan for at least two reasons/assumptions (two being
> all that I can recall):
>
> 1. Caching pages for sequent
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > New TODO entries are:
> > * Add queue of backends waiting for spinlock
>
> I already see:
>
> * Create spinlock sleepers queue so everyone doesn't wake up at once
That is an old copy of the TODO. I reworded it. You will only see this
now:
> 3) I am reading the Solaris Internals book and there is mention of a
> "free behind" capability with large sequential scans. When a large
> sequential scan happens that would wipe out all the old cache entries,
> the kernel detects this and places its previous pages first
> on the free list.
Bruce Momjian <[EMAIL PROTECTED]> 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 hav
Bruce Momjian <[EMAIL PROTECTED]> writes:
> New TODO entries are:
> * Add queue of backends waiting for spinlock
I already see:
* Create spinlock sleepers queue so everyone doesn't wake up at once
BTW, I agree with Vadim's opinion that we should add a new type of lock
(intermediate betwe
> > > 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.
>
> Good question. I know the number of function call
> > > > * 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
> > > * 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 -:)
Da
> 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
> > 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 waiti
15 matches
Mail list logo
