"Tom Lane" <[EMAIL PROTECTED]> writes
>
> In other words, if FSM is wrong you will overwrite valid data? No
> thanks ... this is guaranteed to fail under simple concurrent usage,
> let alone any more interesting scenarios like FSM being actually out of
> date.
>
You are welcome ;-). The FSM race
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> What I did include:
> make ReadPage(+empty_page) treat different of an empty page and non-empty
> one to avoid unnecesary read for new pages, that is:
In other words, if FSM is wrong you will overwrite valid data? No
thanks ... this is guaranteed to
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> I very seriously doubt that there would be *any* win
>
I did a quick proof-concept implemenation to test non-concurrent batch
insertion, here is the result:
Envrionment:
- Pg8.0.1
- NTFS / IDE
-- batch 16 pages extension --
test=# insert into t
"Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> * Alvaro Herrera <[EMAIL PROTECTED]> [08.06.2005 00:39]:
>> Huh, why? You need to grab the relation extension block
>> (LockRelationForExtension in CVS tip).
> Really? Didn't knew that.
> Consider:
> 1) I add 2 pages to the newly-created relatio
* Alvaro Herrera <[EMAIL PROTECTED]> [08.06.2005 00:39]:
> Huh, why? You need to grab the relation extension block
> (LockRelationForExtension in CVS tip).
Really? Didn't knew that.
Consider:
1) I add 2 pages to the newly-created relation
using P_NEW as BlockNumber;
2) then I do LockRelation
On Tue, Jun 07, 2005 at 07:52:57PM +0300, Victor Y. Yegorov wrote:
> * Tom Lane <[EMAIL PROTECTED]> [07.06.2005 07:59]:
> > Why bother? Just write each page when you need to --- there's no law
> > that says you must use P_NEW.
>
> This means 2 things:
> 1) I cannot mix P_NEW and exact-number Read
* Tom Lane <[EMAIL PROTECTED]> [07.06.2005 07:59]:
> Why bother? Just write each page when you need to --- there's no law
> that says you must use P_NEW.
This means 2 things:
1) I cannot mix P_NEW and exact-number ReadBuffer() calls;
2) thus, I have to track next-block-number myself.
Is it so?
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> I very seriously doubt that there would be *any* win, and I doubt even
> more that it could possibly be worth the klugery you'd have to do to
> make it happen. Bear in mind that index access methods are two API
> layers away from md.c --- how will you tra
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Is there any performance benefits if we have a mdextend_several_pages()
> function in md.c?
I very seriously doubt that there would be *any* win, and I doubt even
more that it could possibly be worth the klugery you'd have to do to
make it happen. Bea
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> Why bother? Just write each page when you need to --- there's no law
> that says you must use P_NEW. The hash index type does something pretty
> similar, IIRC.
>
Is there any performance benefits if we have a mdextend_several_pages()
function in md.c? S
"Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> [ scheme involving a predetermined layout of index pages ]
> The question is: allocating pages this way is really ugly, I understand. Is
> there some API that would allow allocating N pages in the bulk way?
Why bother? Just write each page when y
On Mon, Jun 06, 2005 at 10:59:04PM +0300, Victor Y. Yegorov wrote:
> The question is: allocating pages this way is really ugly, I understand. Is
> there some API that would allow allocating N pages in the bulk way?
> Maybe this is a know problem, that has been already solved before?
> Any other id
12 matches
Mail list logo
