Subject | RE: [IB-Architect] Insert Speed |
---|---|
Author | David Schnepper |
Post date | 2000-04-07T23:41:18Z |
For Kinobi - we did look at default page size - and determined that a 4K
default
page size made the most sense. I honestly can't recall if we anyone went
ahead and made the change!
On page allocation from OS -- the suggestion was kicking around for years to
allocate more than one additional page at a time from the OS -- (eg: grow
the file by more than one page at a time - hopefully to reduce OS overhead
and get more contigious blocks) -- I don't recall if anyone experimented
with it.
On the Insert slowdown -- my memory (really foggy in general, and very
foggy on this problem) - my memory on this was something to do with
searching the pages-in-use list for a relation - looking for an
empty-slot on page was part of the bottleneck (not searching the PIP
for a free page).
Dave
-----Original Message-----
From: Jim Starkey [mailto:jas@...]
Sent: Friday, April 07, 2000 3:56 PM
To: IB-Architect@egroups.com; IB-Architect@egroups.com
Subject: Re: [IB-Architect] Insert Speed
At 08:48 AM 4/8/00 +1000, Jan Mikkelsen wrote:
like a argument for a larger (default) page size. 4K, maybe 8k,
would make a great deal more sense for 1k.
Successive page allocation isn't particularly expensive. The
page inventory page is essentially guarenteed to be sitting in
memory and unless the PIP is chaffed, pages will come out
sequentially (wish I could say that about non-extent based
file systems).
But to answer your question: Not to my knowledge. Shall we?
Jim Starkey
------------------------------------------------------------------------
Special Offer-Earn 300 Points from MyPoints.com for trying @Backup
Get automatic protection and access to your important computer files.
Install today:
http://click.egroups.com/1/2344/3/_/_/_/955148305/
------------------------------------------------------------------------
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com
default
page size made the most sense. I honestly can't recall if we anyone went
ahead and made the change!
On page allocation from OS -- the suggestion was kicking around for years to
allocate more than one additional page at a time from the OS -- (eg: grow
the file by more than one page at a time - hopefully to reduce OS overhead
and get more contigious blocks) -- I don't recall if anyone experimented
with it.
On the Insert slowdown -- my memory (really foggy in general, and very
foggy on this problem) - my memory on this was something to do with
searching the pages-in-use list for a relation - looking for an
empty-slot on page was part of the bottleneck (not searching the PIP
for a free page).
Dave
-----Original Message-----
From: Jim Starkey [mailto:jas@...]
Sent: Friday, April 07, 2000 3:56 PM
To: IB-Architect@egroups.com; IB-Architect@egroups.com
Subject: Re: [IB-Architect] Insert Speed
At 08:48 AM 4/8/00 +1000, Jan Mikkelsen wrote:
>Could you explain the thinking behind the question? It sounds
>
>Has anything other than page at a time allocation ever been considered?
>
like a argument for a larger (default) page size. 4K, maybe 8k,
would make a great deal more sense for 1k.
Successive page allocation isn't particularly expensive. The
page inventory page is essentially guarenteed to be sitting in
memory and unless the PIP is chaffed, pages will come out
sequentially (wish I could say that about non-extent based
file systems).
But to answer your question: Not to my knowledge. Shall we?
Jim Starkey
------------------------------------------------------------------------
Special Offer-Earn 300 Points from MyPoints.com for trying @Backup
Get automatic protection and access to your important computer files.
Install today:
http://click.egroups.com/1/2344/3/_/_/_/955148305/
------------------------------------------------------------------------
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com