Обсуждение: v6.4 - What is planned...?
Morning all...
Just curious, but what *is* planned for v6.4? We have a TODO
list, but I imagine there are things on that TODO list that ppl are
planning on for v6.4? Can we add a "planned for v6.4" to various items,
such that ppl have an idea of what they could be expecting? Even a
disclaimer at the top that states that altho "the following items are
planned for v6.4, time might not permit completion"?
With that in mind, is anyone working on 'row level locking'? I
would think that, as far as importance is concerned, that would be one of
the most important features we are missing...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
>
> Morning all...
>
> Just curious, but what *is* planned for v6.4? We have a TODO
> list, but I imagine there are things on that TODO list that ppl are
> planning on for v6.4? Can we add a "planned for v6.4" to various items,
> such that ppl have an idea of what they could be expecting? Even a
> disclaimer at the top that states that altho "the following items are
> planned for v6.4, time might not permit completion"?
>
> With that in mind, is anyone working on 'row level locking'? I
> would think that, as far as importance is concerned, that would be one of
> the most important features we are missing...
We do have in the TODO list:
A dash(-) marks changes to be in the next release.
and appears to be fairly accurate. Haven't hear much about people
claiming items for 6.4 yet.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
On Sat, 6 Jun 1998, Bruce Momjian wrote: > > Morning all... > > > > Just curious, but what *is* planned for v6.4? We have a TODO > > list, but I imagine there are things on that TODO list that ppl are > > planning on for v6.4? Can we add a "planned for v6.4" to various items, > > such that ppl have an idea of what they could be expecting? Even a > > disclaimer at the top that states that altho "the following items are > > planned for v6.4, time might not permit completion"? > > > > With that in mind, is anyone working on 'row level locking'? I > > would think that, as far as importance is concerned, that would be one of > > the most important features we are missing... The bit's I'm working on for 6.4 (mostly Java/JDBC) are listed at http://www.retep.org.uk/postgres > > We do have in the TODO list: > > A dash(-) marks changes to be in the next release. > > and appears to be fairly accurate. Haven't hear much about people > claiming items for 6.4 yet. I should be down already for one of the large object bits -- Peter T Mount peter@retep.org.uk or petermount@earthling.net Main Homepage: http://www.retep.org.uk ************ Someday I may rebuild this signature completely ;-) ************ Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
> > > > A dash(-) marks changes to be in the next release. > > > > and appears to be fairly accurate. Haven't hear much about people > > claiming items for 6.4 yet. > > I should be down already for one of the large object bits You are. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
Well, my plans for 6.4: 1. Btree: use TID as (last) part of index key; prepare btree for low-level locking (it's now possible to lose root page). 2. Vacuum: speed up index cleaning; release pg_class lock after updation statistic for a table. 3. Buffer manager: error handling broken; should flush only buffers changed by backend itself. 4. Implement shared catalog cache; get rid of invalidation code. 5. Subselects: in target list; in FROM. 6. Transaction manager: get rid of pg_variable; do not prefetch XIDs; nested transactions; savepoints. Vadim
> > Well, my plans for 6.4: > > 1. Btree: use TID as (last) part of index key; prepare btree > for low-level locking (it's now possible to lose root page). > 2. Vacuum: speed up index cleaning; release pg_class lock after > updation statistic for a table. > 3. Buffer manager: error handling broken; should flush only > buffers changed by backend itself. > 4. Implement shared catalog cache; get rid of invalidation code. > 5. Subselects: in target list; in FROM. > 6. Transaction manager: get rid of pg_variable; do not prefetch > XIDs; nested transactions; savepoints. That's quite a list. Vadim, I hate to ask, but how about the buffering of pg_log writes and the ability to do sync() every 30 seconds then flush pg_log, so we can have crash reliability without doing fsync() on every transaction. We discussed this months ago, and I am not sure if you were thinking of doing this for 6.4. I can send the old posts if that would help. It would certainly increase our speed vs. fsync(). -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
I noticed that the way Lotus Notes updates there database to a new version is through something similar to our Vacuum. In other word, if you upgrade the server the databases are still stored in the old format. To get the new format you would perform a Vacuum and this would rewrite the database into the new format. Is this a possible solution to simplifying the steps in the upgrade process? Check out the article about some of the new database features planed for Notes 5. http://www.notes.net/today.nsf/b1d67fedee86c741852563cc005019c5/9489b036757596c58525660900627762?OpenDocument Oliver
On Sat, 6 Jun 1998, Bruce Momjian wrote:
> >
> >
> > Morning all...
> >
> > Just curious, but what *is* planned for v6.4? We have a TODO
> > list, but I imagine there are things on that TODO list that ppl are
> > planning on for v6.4? Can we add a "planned for v6.4" to various items,
> > such that ppl have an idea of what they could be expecting? Even a
> > disclaimer at the top that states that altho "the following items are
> > planned for v6.4, time might not permit completion"?
> >
> > With that in mind, is anyone working on 'row level locking'? I
> > would think that, as far as importance is concerned, that would be one of
> > the most important features we are missing...
>
> We do have in the TODO list:
>
> A dash(-) marks changes to be in the next release.
>
Does it means that items begining with a dash instead of an asterisk
will be in the next release ?
I can't see any item begining with dash on TODO list v6.3.2 !
Jose'
Bruce Momjian wrote:
>
> > 6. Transaction manager: get rid of pg_variable; do not prefetch
> > XIDs; nested transactions; savepoints.
>
> That's quite a list.
>
> Vadim, I hate to ask, but how about the buffering of pg_log writes and
> the ability to do sync() every 30 seconds then flush pg_log, so we can
> have crash reliability without doing fsync() on every transaction.
>
> We discussed this months ago, and I am not sure if you were thinking of
> doing this for 6.4. I can send the old posts if that would help. It
> would certainly increase our speed vs. fsync().
I never forgot about this :)
Ok, but let's wait ~ Aug 1st: I'm not sure that I'll have
time for 6. and delayed fsync implemetation depends on
design of transaction manager...
BTW, I have another item:
7. Re-use transaction XID (no commit --> no fsync) of read only
transactions (SELECTs could be left un-commited!).
And more about performance of sequential scans:
as you know HeapTupleSatisfies can perfome scan key test and
so bypass expensive HeapTupleSatisfiesVisibility test for
unqualified tuples ... but this ability is never used by
SeqScan!!! ALL visible tuples are returned to top level
ExecScan and qualified by ExecQual - this is very very bad.
SeqScan should work like IndexScan: put quals from WHERE into
ScanKey-s for low level heap scan functions (it's now
possible for ANDs but could be extended for ORs too)...
Another issue - handling of functions with constant args
in queries - for query
select * from T where A = upper ('bbb')
function upper ('bbb') will be executed for each tuple in T!
More of that - if there is index on T(A) then this index will
not be used for this query!
Obviously, upper ('bbb') should be executed (by Executor, not
parser/planner) once: new Param type (PARAM_EXEC) implemented
for subselects could help here too...
Vadim
Bruce Momjian wrote: > > > > > > Morning all... > > > > Just curious, but what *is* planned for v6.4? We have a TODO > > list, but I imagine there are things on that TODO list that ppl are > > planning on for v6.4? Can we add a "planned for v6.4" to various items, > > such that ppl have an idea of what they could be expecting? Even a > > disclaimer at the top that states that altho "the following items are > > planned for v6.4, time might not permit completion"? > > > > With that in mind, is anyone working on 'row level locking'? I > > would think that, as far as importance is concerned, that would be one of > > the most important features we are missing... > > We do have in the TODO list: > > A dash(-) marks changes to be in the next release. > > and appears to be fairly accurate. Haven't hear much about people > claiming items for 6.4 yet. > Bruce, Item "Remove restriction that ORDER BY field must be in SELECT list", in the TODO list, has been completed. Stephan or Anyone, What is the status of the HAVING clause? I noticed that it almost made the 6.3.2 cut, but I haven't heard any thing for a while. I would really like to see this feature implemented. It is important to my user community. Everyone especially Vadim, I agree with Marc. Row locking is huge. In my user community, it is unacceptable to wait for up to 30 minutes (or even one minute) for a report to finish so that a users can commit an invoice or commit a change to a customer attribute. I can deal with it for now because my databases are batch loaded for reporting purposes only. However, I plan to go forward with some pretty important projects that assume that record/page locking will exist within the next 12 month or so. Am I being too presumptuous?
> > On Sat, 6 Jun 1998, Bruce Momjian wrote: > > > > > > > > > > Morning all... > > > > > > Just curious, but what *is* planned for v6.4? We have a TODO > > > list, but I imagine there are things on that TODO list that ppl are > > > planning on for v6.4? Can we add a "planned for v6.4" to various items, > > > such that ppl have an idea of what they could be expecting? Even a > > > disclaimer at the top that states that altho "the following items are > > > planned for v6.4, time might not permit completion"? > > > > > > With that in mind, is anyone working on 'row level locking'? I > > > would think that, as far as importance is concerned, that would be one of > > > the most important features we are missing... > > > > We do have in the TODO list: > > > > A dash(-) marks changes to be in the next release. > > > Does it means that items begining with a dash instead of an asterisk > will be in the next release ? > I can't see any item begining with dash on TODO list v6.3.2 ! On the web site. 6.3.2 TODO doesn't have dashes because they were removed prior to the release. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> I never forgot about this :)
> Ok, but let's wait ~ Aug 1st: I'm not sure that I'll have
> time for 6. and delayed fsync implemetation depends on
> design of transaction manager...
Thanks. Makes sense.
>
> BTW, I have another item:
>
> 7. Re-use transaction XID (no commit --> no fsync) of read only
> transactions (SELECTs could be left un-commited!).
>
> And more about performance of sequential scans:
> as you know HeapTupleSatisfies can perfome scan key test and
> so bypass expensive HeapTupleSatisfiesVisibility test for
> unqualified tuples ... but this ability is never used by
> SeqScan!!! ALL visible tuples are returned to top level
> ExecScan and qualified by ExecQual - this is very very bad.
> SeqScan should work like IndexScan: put quals from WHERE into
> ScanKey-s for low level heap scan functions (it's now
> possible for ANDs but could be extended for ORs too)...
>
> Another issue - handling of functions with constant args
> in queries - for query
>
> select * from T where A = upper ('bbb')
>
> function upper ('bbb') will be executed for each tuple in T!
> More of that - if there is index on T(A) then this index will
> not be used for this query!
> Obviously, upper ('bbb') should be executed (by Executor, not
> parser/planner) once: new Param type (PARAM_EXEC) implemented
> for subselects could help here too...
I see what you are saying.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
> > We do have in the TODO list: > > > > A dash(-) marks changes to be in the next release. > > > > and appears to be fairly accurate. Haven't hear much about people > > claiming items for 6.4 yet. > > > > Bruce, > Item "Remove restriction that ORDER BY field must be in SELECT list", in the > TODO list, has been completed. Dash added to TODO. Gee, I could swear I marked that as complete already. Strange. > > Stephan or Anyone, > What is the status of the HAVING clause? I noticed that it almost made the > 6.3.2 cut, but I haven't heard any thing for a while. I would really like to > see this feature implemented. It is important to my user community. It works, but has some bugs, so we dis-abled it in gram.y until it was working perfectly. I can forward the bug reports if you wish. Stephan was working on it, but I haven't heard anything from him in months. You are welcome to fix it. > > Everyone especially Vadim, > I agree with Marc. Row locking is huge. In my user community, it is > unacceptable to wait for up to 30 minutes (or even one minute) for a report to > finish so that a users can commit an invoice or commit a change to a customer > attribute. I can deal with it for now because my databases are batch loaded > for reporting purposes only. However, I plan to go forward with some pretty > important projects that assume that record/page locking will exist within the > next 12 month or so. Am I being too presumptuous? Sounds like you need dirty read rather than row locking. If they lock a row or the entire table, it still would cause the program to stall. I am not saying you don't need row or page locking, just that this may not help even if we had it. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)