
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 


Sat, 6 Jun 1998 13:01:50 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
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...

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)

Sat, 6 Jun 1998 17:32:33 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] v6.4 - What is planned...?
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


Sun, 7 Jun 1998 17:41:39 +0100 (BST)
Peter T Mount <psqlhack@retep.org.uk>
Re: [HACKERS] v6.4 - What is planned...?
> > 
> > 	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)

Sun, 7 Jun 1998 13:10:59 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] v6.4 - What is planned...?
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

Mon, 08 Jun 1998 14:37:01 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] v6.4 - What is planned...?
> 
> 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)

Mon, 8 Jun 1998 11:29:12 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] v6.4 - What is planned...?
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



Mon, 08 Jun 1998 13:03:53 -0400
mark metzger <mmetzger@ksminc.com>
[HACKERS] Upgrade improvements.
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'


Tue, 9 Jun 1998 10:21:07 +0000 (UTC)
"Jose' Soares Da Silva" <sferac@bo.nettuno.it>
Re: [HACKERS] v6.4 - What is planned...?


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?



Tue, 09 Jun 1998 09:44:12 -0400
David Hartwig <daveh@insightdist.com>
Re: [HACKERS] v6.4 - What is planned...?
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

Tue, 09 Jun 1998 21:54:12 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] v6.4 - What is planned...?
> 
> 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)

Tue, 9 Jun 1998 12:42:37 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] v6.4 - What is planned...?
> > 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)

Tue, 9 Jun 1998 13:25:09 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] v6.4 - What is planned...?
> 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)

Tue, 9 Jun 1998 13:27:18 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] v6.4 - What is planned...?