[HACKERS] : [HACKERS] ????: [HACKERS] Otvet: WAL and indexes (Re: [HACKERS] WAL status todo)

2000-10-17 Thread Mikheev, Vadim
Just a confirmation. Do you plan overwrite storage manager also in 7.2 ? Yes if I'll get enough time. Vadim

RE: [HACKERS] Re: ?????: ?????: WAL and indexes (Re: [HACKERS] WAL status todo)

2000-10-17 Thread Mikheev, Vadim
I'm still nervous about how we're going to test the WAL code adequately for the lesser-used index types. Any ideas out there? First, seems we'll have to follow to what you've proposed for their redo/undo: log each *fact* of changing a page to know was update op done entirely or not (rebuild

Re: [HACKERS] Otvet: WAL and indexes (Re: [HACKERS] WAL status todo)

2000-10-16 Thread Alfred Perlstein
* Mikheev, Vadim [EMAIL PROTECTED] [001016 09:33] wrote: I don't understand why WAL needs to log internal operations of any of the index types. Seems to me that you could treat indexes as black boxes that are updated as side effects of WAL log items for heap tuples: when adding a heap tuple

[HACKERS] Re: : WAL and indexes (Re: [HACKERS] WAL status todo)

2000-10-16 Thread Tom Lane
"Mikheev, Vadim" [EMAIL PROTECTED] writes: I don't understand why WAL needs to log internal operations of any of the index types. Seems to me that you could treat indexes as black boxes that are updated as side effects of WAL log items for heap tuples: when adding a heap tuple as a result of

Re: [HACKERS] Re: Otvet: WAL and indexes (Re: [HACKERS] WAL status todo)

2000-10-16 Thread Alfred Perlstein
* Tom Lane [EMAIL PROTECTED] [001016 09:47] wrote: "Mikheev, Vadim" [EMAIL PROTECTED] writes: I don't understand why WAL needs to log internal operations of any of the index types. Seems to me that you could treat indexes as black boxes that are updated as side effects of WAL log items

[HACKERS] Re: : : WAL and indexes (Re: [HACKERS] WAL status todo)

2000-10-16 Thread Tom Lane
"Mikheev, Vadim" [EMAIL PROTECTED] writes: And how could I use such records on recovery being unable to know what data columns represent keys, what functions should be used for ordering? Um, that's not built into the index either, is it? OK, you win ... I'm still nervous about how we're

[HACKERS] : [HACKERS] Otvet: WAL and indexes (Re: [HACKERS] WAL status todo)

2000-10-16 Thread Mikheev, Vadim
One of the purposes of WAL is immediate removing tuples inserted by aborted xactions. I want make VACUUM *optional* in future - space must be available for reusing without VACUUM. And this is first, very small, step in this direction. Why would vacuum become optional? Would WAL offer an

Re: [HACKERS] Re: ?????: ?????: WAL and indexes (Re: [HACKERS] WAL status todo)

2000-10-16 Thread Bruce Momjian
"Mikheev, Vadim" [EMAIL PROTECTED] writes: And how could I use such records on recovery being unable to know what data columns represent keys, what functions should be used for ordering? Um, that's not built into the index either, is it? OK, you win ... I'm still nervous about how

Re: [HACKERS] WAL status todo

2000-10-15 Thread Martin A. Marques
On Sat, 14 Oct 2000, Vadim Mikheev wrote: Well, hopefully WAL will be ready for alpha testing in a few days. Unfortunately at the moment I have to step side from main stream to implement new file naming, the biggest todo for integration WAL into system. I would really appreciate any help

[HACKERS] : [HACKERS] WAL status todo

2000-10-15 Thread Mikheev, Vadim
Well, hopefully WAL will be ready for alpha testing in a few days. Unfortunately at the moment I have to step side from main stream to implement new file naming, the biggest todo for integration WAL into system. I would really appreciate any help in

[HACKERS] WAL status todo

2000-10-14 Thread Vadim Mikheev
Well, hopefully WAL will be ready for alpha testing in a few days. Unfortunately at the moment I have to step side from main stream to implement new file naming, the biggest todo for integration WAL into system. I would really appreciate any help in the following issues (testing can start