Thread: 7.1 items
Am I correct that we are targeting all these for 7.1? WAL/write ahead logTOAST/long tuplesouter joinsquery tree redesign -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian wrote: > > > > Am I correct that we are targeting all these for 7.1? > > > > WAL/write ahead log > > TOAST/long tuples > > outer joins > > query tree redesign > > There have been talks about redesigning fmgr and pl-function > interface as well ;) Oops, yes: WAL/write ahead logTOAST/long tuplesouter joinsquery tree redesignfunction manager redesign What year to we want to release 7.1? :-) -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian writes: > Oops, yes: > > WAL/write ahead log > TOAST/long tuples > outer joins > query tree redesign > function manager redesign > > What year to we want to release 7.1? :-) ISTM that any one of these features could lead to a release of its own right. Considering that at least four of these five were planned for 7.0 we perhaps shouldn't be overly enthusiastic (although ambitious plans never hurt). FWIW, my own plans for 7.1 revolve around ACL enhancements and build system clean up. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On Wed, 5 Apr 2000, Bruce Momjian wrote: > > Bruce Momjian wrote: > > > > > > Am I correct that we are targeting all these for 7.1? > > > > > > WAL/write ahead log > > > TOAST/long tuples > > > outer joins > > > query tree redesign > > > > There have been talks about redesigning fmgr and pl-function > > interface as well ;) > > Oops, yes: > > WAL/write ahead log > TOAST/long tuples > outer joins > query tree redesign > function manager redesign > > What year to we want to release 7.1? :-) Based on this last one ... Jan/Feb 1st, 2001 would be nice? :)
On Thu, 6 Apr 2000, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Oops, yes:
> >
> > WAL/write ahead log
> > TOAST/long tuples
> > outer joins
> > query tree redesign
> > function manager redesign
> >
> > What year to we want to release 7.1? :-)
If all will right (and major developers will agree) I plan PREPARE/EXECUTE
commands and changes in SPI background for plan saving (query cache).
> FWIW, my own plans for 7.1 revolve around ACL enhancements and build
> system clean up.
And if will implemented new ACL, I plan CREATE PROFILE feature (like Oracle)
for better user control (connection elapsed time, time period for connection,
default ACL mask ..ect.) .
Karel
> Am I correct that we are targeting all these for 7.1?
> outer joins
> query tree redesign
We are pretty much agreed that outer joins will be much easier with a
query tree redesign. But if anyone wants to try shoehorning at least a
simple example of outer joins into the current design they are welcome
to try.
I'm also planning on working on the multi-language support, using the
SQL92 NATIONAL CHARACTER/CHARACTER SET/COLLATION features.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Karel Zak <zakkr@zf.jcu.cz> writes:
>>>> WAL/write ahead log
>>>> TOAST/long tuples
>>>> outer joins
>>>> query tree redesign
>>>> function manager redesign
>>>>
>>>> What year to we want to release 7.1? :-)
> If all will right (and major developers will agree) I plan PREPARE/EXECUTE
> commands and changes in SPI background for plan saving (query cache).
Given that there is going to be a querytree redesign for 7.1, I'd
suggest holding off on prepared plans until 7.2. Otherwise it's
going to be a mess.
The good thing about the above list is that we have four essentially
independent major projects. (I think outer joins are a portion of the
querytree work, not a separate item.) So work on them can proceed in
parallel. And, if it gets to be September-ish and only two or three
are done, we can make a 7.1 release and still feel pretty good about
having some nice stuff.
This does bring up a suggestion that Jan has made in the past. Perhaps
it would be a good idea if we create a separate CVS branch for each of
these major projects, so that people could work on that project
independently of the others. When a project is done, we merge it back
into the main branch. Then it's no problem if one of the projects is
broken temporarily, or not ready to go when we want to release 7.1.
OTOH, managing separate CVS branches might be a real pain in the neck,
especially for developers who need to deal with more than one project.
I've never done it so I don't have a feeling for what it would take.
But the Mozilla people do this sort of thing all the time, so it can't
be that bad.
regards, tom lane
> >>>> WAL/write ahead log > >>>> TOAST/long tuples > >>>> outer joins > >>>> query tree redesign > >>>> function manager redesign > >>>> > >>>> What year to we want to release 7.1? :-) > > > If all will right (and major developers will agree) I plan PREPARE/EXECUTE > > commands and changes in SPI background for plan saving (query cache). > > Given that there is going to be a querytree redesign for 7.1, I'd > suggest holding off on prepared plans until 7.2. Otherwise it's > going to be a mess. Any chance for dirty read? Waiting for transaction end on inserts with duplicates on unique keys in transactions can be a lot of fun. Regards Theo
> > >>>> WAL/write ahead log > > >>>> TOAST/long tuples > > >>>> outer joins > > >>>> query tree redesign > > >>>> function manager redesign > > >>>> > > >>>> What year to we want to release 7.1? :-) > > > > > If all will right (and major developers will agree) I plan PREPARE/EXECUTE > > > commands and changes in SPI background for plan saving (query cache). > > > > Given that there is going to be a querytree redesign for 7.1, I'd > > suggest holding off on prepared plans until 7.2. Otherwise it's > > going to be a mess. > > Any chance for dirty read? Waiting for transaction end on inserts with > duplicates on unique keys in transactions can be a lot of fun. But we have committed read with no block. Why would you want dirty read. Chapter 10 of my book is about transactions and locking. Of course, I may be missing something here. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Thu, 6 Apr 2000, Tom Lane wrote:
> Karel Zak <zakkr@zf.jcu.cz> writes:
>
> > If all will right (and major developers will agree) I plan PREPARE/EXECUTE
> > commands and changes in SPI background for plan saving (query cache).
>
> This does bring up a suggestion that Jan has made in the past. Perhaps
> it would be a good idea if we create a separate CVS branch for each of
> these major projects, so that people could work on that project
> independently of the others. When a project is done, we merge it back
> into the main branch. Then it's no problem if one of the projects is
> broken temporarily, or not ready to go when we want to release 7.1.
I agree.
Karel
On Thu, 6 Apr 2000, Tom Lane wrote:
> Karel Zak <zakkr@zf.jcu.cz> writes:
> >>>> WAL/write ahead log
> >>>> TOAST/long tuples
> >>>> outer joins
> >>>> query tree redesign
> >>>> function manager redesign
> >>>>
> >>>> What year to we want to release 7.1? :-)
>
> > If all will right (and major developers will agree) I plan PREPARE/EXECUTE
> > commands and changes in SPI background for plan saving (query cache).
>
> Given that there is going to be a querytree redesign for 7.1, I'd
> suggest holding off on prepared plans until 7.2. Otherwise it's
> going to be a mess.
>
> The good thing about the above list is that we have four essentially
> independent major projects. (I think outer joins are a portion of the
> querytree work, not a separate item.) So work on them can proceed in
> parallel. And, if it gets to be September-ish and only two or three
> are done, we can make a 7.1 release and still feel pretty good about
> having some nice stuff.
>
> This does bring up a suggestion that Jan has made in the past. Perhaps
> it would be a good idea if we create a separate CVS branch for each of
> these major projects, so that people could work on that project
> independently of the others. When a project is done, we merge it back
> into the main branch. Then it's no problem if one of the projects is
> broken temporarily, or not ready to go when we want to release 7.1.
>
> OTOH, managing separate CVS branches might be a real pain in the neck,
> especially for developers who need to deal with more than one project.
> I've never done it so I don't have a feeling for what it would take.
> But the Mozilla people do this sort of thing all the time, so it can't
> be that bad.
I've only ever seen it done for the kernel of FreeBSD, and very very
rarely at that ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org