"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
I need your advice.
For on-disk bitmap I run a list of TIDs.
TIDs are stored in pages as an array, page's opaque data holds an array of
bits, indicating whether corresponding TID has been deleted and should be
skipped during the scan.
Pages, that contain TIDs list, are organized in extents, each
13 matches
Mail list logo
