On 10/24/07, Greg Smith <[EMAIL PROTECTED]> wrote:
> 1) Make a converted copy of the existing CVS repository
> 2) Keep the mirrored repo up to date with new commits
> 3) Provide working guidelines so that developers can use the new VCS to
> build local patches and improve their productivity
> 4) Ge
On 10/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi,
> i am new in this, and i need help with catalog system of postgresql, i need
> know
> how are the relationship between the tables of the system catalog, and how
> work
> each table, if anybody know about this please, answer me.
>
>
On Tue, 23 Oct 2007, David Fetter wrote:
If Mercurial has a similar migration/legacy support path, then by all
means, let's try that out, too.
There's an import tool at http://hg.beekhof.net/hg/cvs-import but the
experience of the Mozilla project suggests it's on the buggy and slow side
for
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> It might be worth applying a simple tag (but not a branch) at the end
> (and maybe also at the start) of each checkpoint/fest/whatever
Perhaps, though of course one could easily enough pull a CVS snapshot by
date instead (especially if we stick to a pr
Tom Lane wrote:
Now to the extent that regular commit-fests keep patch development
more closely aligned with the mainline CVS, the fest proposal might
indirectly alleviate your pain. But I'd think that snaps taken
*after* the fests would be the best for that, as they'd be closer
to what any su
Josh Berkus <[EMAIL PROTECTED]> writes:
> If we had milestone snapshots of each 2 months ... probably just before
> each commit-fest ... and kept them available on ftp.postgresql.org until
> official beta, then it would make it easier for testers to have a common
> point of reference to work wit
Tom,
> Since there are always bugs, and we're certainly not going to schedule a
> round of formal beta testing right after each commit-fest, I should
> think that tarballs made right after a commit-fest would be particularly
> unlikely to be good candidates for non-developer use.
>
> (Actually, it
This does not seem right:
regression=# select alias,description,token from ts_debug('foo-8.3beta');
alias | description | token
-+-+-
numhword| Hyphenated word, letters and digits | foo-8.3
Josh Berkus <[EMAIL PROTECTED]> writes:
> Plus, for the developers and other people who really need to be
> bleeding-edge, this new plan would result in less-unstable snapshots every
> 2 months with defined feature sets which someone who wanted to run them at
> their own risk could. Which would
Josh Berkus <[EMAIL PROTECTED]> writes:
> Mind you, I'm in favor of one. A new SCM would make some other development
> tasks easier. However, I'm reluctant to open the can-of-worms which is the
> "what SCM should we use" discussion again, and complicate something which
> we seem to have consens
Simon,
> Maybe. I'm looking for ways to increase the amount of development time
> we have compared with time releasing. If we release twice as often, we
> won't get twice the beta test contribution from everybody, so our code
> will be less robust, which will hurt us in the long run.
I don't thin
Joshua D. Drake wrote:
>
> We develop and commit like normal *until* the community feels there is
> enough for release. Then we announce a feature freeze.
I think you just described what will happen in reality regardless
of whatever is decided to be an official "plan". :) I don't
think that's n
On Tue, 2007-10-23 at 09:28 -0700, Joshua D. Drake wrote:
> On Tue, 23 Oct 2007 09:29:58 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > I'd suggest we have multiple checkpoints during the cycle.
> > > Checkpoint is a "patch queue blitz" where we sto
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Just for clarification.
> Are you going to make these changes in the 8.3 beta test period?
Yes, I committed them a couple hours ago.
regards, tom lane
---(end of broadcast)---
TIP 7
Folks,
> You are way ahead of us here. And my vote *still* goes to Mercurial, if
> we're picking SCMs.
Will a new SCM actually make this easier, or are people just using it as an
excuse?
Mind you, I'm in favor of one. A new SCM would make some other development
tasks easier. However, I'm relu
On Tue, Oct 23, 2007 at 06:19:42PM -0400, Andrew Dunstan wrote:
> David Fetter wrote:
> >On Tue, Oct 23, 2007 at 04:59:51PM -0400, Chris Browne wrote:
> >>[EMAIL PROTECTED] (Tom Lane) writes:
> >>>Simon Riggs <[EMAIL PROTECTED]> writes:
> >>>
> I'd suggest we have multiple checkpoints dur
Just for clarification.
Are you going to make these changes in the 8.3 beta test period?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> If I am reading the state machine in wparser_def.c correctly, the
> three classifications of words that the default parser knows are
>
> lword Composed entirely
Tom,
> Personally I feel every six weeks would be too short: we'd be talking
> only a month of work between commit-fests. I like a two-month cycle
> partly because it wouldn't rotate relative to the calendar: we'd always
> know that the first half of every odd-numbered month, or something like
>
David Fetter wrote:
On Tue, Oct 23, 2007 at 04:59:51PM -0400, Chris Browne wrote:
[EMAIL PROTECTED] (Tom Lane) writes:
Simon Riggs <[EMAIL PROTECTED]> writes:
I'd suggest we have multiple checkpoints during the cycle.
Checkpoint is a "patch queue blitz" where we stop developin
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
Anyway, is there anyone who thinks the "cycle the queue every 6 weeks or 2
months or suitable short period" is a *bad* idea? It might be hard to pull
off, but we won't know until we try.
It seems worth a try --- we can certai
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I'm fairly resistant to putting less-than-ready code in the tree, I must
say.
Me too, at least if "less than ready" means "unstable". The committed
code has to always be solid enough to let everybody continue working on
thei
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Hannu Krosing wrote:
> ?hel kenal p?eval, R, 2007-10-19 kell 15:42, kirjutas Joe Conway:
> > Decibel! wrote:
> > > O
Josh Berkus <[EMAIL PROTECTED]> writes:
> Anyway, is there anyone who thinks the "cycle the queue every 6 weeks or 2
> months or suitable short period" is a *bad* idea? It might be hard to pull
> off, but we won't know until we try.
It seems worth a try --- we can certainly abandon it easily i
Michael Glaesemann <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> asciiword
>>> word
>>> numword
> No huge preference, but I see benefit in what Gregory was saying re:
> asciiword, alphaword, alnumword. word itself is pretty general, while
> alphaword ties it much closer to its intended me
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'm fairly resistant to putting less-than-ready code in the tree, I must
> say.
Me too, at least if "less than ready" means "unstable". The committed
code has to always be solid enough to let everybody continue working on
their own bits. However, in
On Tue, Oct 23, 2007 at 04:59:51PM -0400, Chris Browne wrote:
> [EMAIL PROTECTED] (Tom Lane) writes:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> I'd suggest we have multiple checkpoints during the cycle.
> >> Checkpoint is a "patch queue blitz" where we stop developing and
> >> reduce the queu
[EMAIL PROTECTED] (Tom Lane) writes:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> I'd suggest we have multiple checkpoints during the cycle. Checkpoint is
>> a "patch queue blitz" where we stop developing and reduce the queue to
>> nothing. Perhaps a two-week period where everybody helps reduce the
On Oct 23, 2007, at 12:09 , Alvaro Herrera wrote:
Tom Lane wrote:
OK, so with that and Michael's suggestion we have
asciiword
word
numword
asciihword
hword
numhword
hword_asciipart
hword_part
hword_numpart
Sold?
Sol
Gregory Stark wrote:
> "Josh Berkus" <[EMAIL PROTECTED]> writes:
>
> > All,
> >
> >> We could release "alpha" releases. But that assumes that these reviews
> >> actually result in stuff getting committed even if they're not 100%
> >> complete. I think that would be a good thing but I don't think e
Gregory Stark wrote:
The problem I ran into was that by the time I had them all wrapped up major
new commits to the CVS tree made it uninteresting to benchmark the snapshot I
had.
That's going to be a problem with any snapshot approach. For the most
part, interesting patches are going to
Greg,
> The problem I ran into was that by the time I had them all wrapped up major
> new commits to the CVS tree made it uninteresting to benchmark the snapshot
> I had. Also I think a new version of HOT had been posted.
Yeah, that's exactly what I was thinking of. The Sun benchmarking folks wo
Magnus Hagander wrote:
> Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> >> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> >>> At least if we think it's more than a very narrow legitimate use, compared
> >>> to the number of ppl making the mistake.
> >
> >> Did we ever come to
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> All,
>
>> We could release "alpha" releases. But that assumes that these reviews
>> actually result in stuff getting committed even if they're not 100%
>> complete. I think that would be a good thing but I don't think everyone
>> else agrees. Also, not a
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>> At least if we think it's more than a very narrow legitimate use, compared
>>> to the number of ppl making the mistake.
>
>> Did we ever come to a conclusion on this or not? I've cha
Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
>> I know I just love it when a customer breaks something and I ask what
>> changed and it is 56 different things ;)
>>
>> My question is.. with a checkpoint every 2 months, would it make it
>> very easy to release every 6 (or
All,
> We could release "alpha" releases. But that assumes that these reviews
> actually result in stuff getting committed even if they're not 100%
> complete. I think that would be a good thing but I don't think everyone
> else agrees. Also, not all reviewers are committers.
This is what I'm thi
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> I know I just love it when a customer breaks something and I ask what
> changed and it is 56 different things ;)
>
> My question is.. with a checkpoint every 2 months, would it make it
> very easy to release every 6 (or 4 or 3 or 9) months? I am not
I find a number of places coded like this:
static TParserStateActionItem actionTPS_InHyphenLatWordFirst[] = {
{p_isEOF, 0, A_POP, TPS_Null, 0, NULL},
{p_islatin, 0, A_NEXT, TPS_InHyphenLatWord, 0, NULL},
{p_isnonlatin, 0, A_NEXT, TPS_InHyphenUWord, 0, NULL},
{p_isdi
On Mon, 2007-10-22 at 15:40 +0200, Cédric Villemain wrote:
> Does postgresql use posix_fallocate ?
No.
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL P
On Tue, 23 Oct 2007 12:45:14 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> Joshua D. Drake wrote:
> > We develop and commit like normal *until* the community feels there
> > is enough for release. Then we announce a feature freeze.
> >
> >
>
> No, I think this is hopeless on several
Joshua D. Drake wrote:
We develop and commit like normal *until* the community feels there is
enough for release. Then we announce a feature freeze.
No, I think this is hopeless on several grounds. First, it increases
uncertainty. People need to be able to work towards a target. Second,
On 10/24/07, David Fetter <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23, 2007 at 09:39:39AM +0100, Gregory Stark wrote:
> >
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >
> > > I'd rather encourage people to work in an incremental,
> > > not-so-big-bang fashion. Obviously one of the requirements for
On Tue, 23 Oct 2007 09:29:58 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I'd suggest we have multiple checkpoints during the cycle.
> > Checkpoint is a "patch queue blitz" where we stop developing and
> > reduce the queue to nothing. Perhaps a two-week p
On Tue, Oct 23, 2007 at 09:39:39AM +0100, Gregory Stark wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > I'd rather encourage people to work in an incremental,
> > not-so-big-bang fashion. Obviously one of the requirements for
> > that will be quicker review turnaround and commit, so that
On Tue, 23 Oct 2007 09:07:52 -0400
"Jonah H. Harris" <[EMAIL PROTECTED]> wrote:
> On 10/23/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > It would be a major mistake to think there's no work left to
> > do in improving update performance.
>
> Agreed. That would be a very short-sighted move.
>
On Tue, 23 Oct 2007 11:00:59 +0200
Rafael Martinez <[EMAIL PROTECTED]> wrote:
> Tatsuo Ishii wrote:
>
> >
> > +1. Shorter release cycles are maybe good for fancy GUI oriented
> > applications, but not so good for DBMS.
> > --
>
> We are always 1 year back the main release. We are testing and pl
On Tue, 23 Oct 2007 17:28:14 +0900 (JST)
Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> > On Mon, 22 Oct 2007, Tom Lane wrote:
> > I personally think that shorting the minor release cycle time too
> > far is counterproductive anyway. From the DBA and system
> > administrator perspective, new version
Gregory Stark <[EMAIL PROTECTED]> writes:
> Out of curiosity would the foo in foo-bär or the foo-beta1 be a
> hword_asciipart or a hword_part/hword_numpart?
foo would be hword_asciipart independently of what was in the other
parts of the hword. AFAICS this is what you want for the purpose,
which
>>> On Mon, Oct 22, 2007 at 5:04 PM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
> Oops. That is not logically equivalent. We want to delete WHERE NOT
> EXISTS; the logic of that suggestion is backwards.
>
> Disregard that last post, please.
Maybe that last post shouldn't be totally disr
"Tom Lane" <[EMAIL PROTECTED]> writes:
> hword_asciipart
> hword_part
> hword_numpart
Out of curiosity would the foo in foo-bär or the foo-beta1 be a
hword_asciipart or a hword_part/hword_numpart?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
--
Tom Lane wrote:
> OK, so with that and Michael's suggestion we have
>
> asciiword
> word
> numword
>
> asciihword
> hword
> numhword
>
> hword_asciipart
> hword_part
> hword_numpart
>
> Sold?
Sold here.
--
Alvaro Herrera
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> If we were doing it from scratch I would suggest using longer names. At the
>> least I would still suggest using "ascii" or "asciiword" instead of "aword".
> +1 for asciiword; "aword" sounds too much like "a word" which is not th
Tom, all:
> > I'd suggest we have multiple checkpoints during the cycle. Checkpoint is
> > a "patch queue blitz" where we stop developing and reduce the queue to
> > nothing. Perhaps a two-week period where everybody helps reduce the
> > queue, not just Tom and Bruce. Every outstanding patch gets
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > I wrote:
> >> Maybe "aword", "word", and "numword"?
> >
> > Does the lack of response mean people are satisfied with that?
>
> Sorry, I had a couple responses partially written but never finished.
>
> If we were doing it from sc
Tom Lane wrote:
> Michael Glaesemann <[EMAIL PROTECTED]> writes:
> > On Oct 23, 2007, at 10:42 , Tom Lane wrote:
> >> apart_hwordPart of hyphenated word, all ASCII letters
> >> part_hword Part of hyphenated word, all letters
> >> numpart_hword Part of hyphenated word, mixed letters and
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I wrote:
>> Maybe "aword", "word", and "numword"?
>
> Does the lack of response mean people are satisfied with that?
Sorry, I had a couple responses partially written but never finished.
If we were doing it from scratch I would suggest using longer names.
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On Oct 23, 2007, at 10:42 , Tom Lane wrote:
>> apart_hword Part of hyphenated word, all ASCII letters
>> part_hword Part of hyphenated word, all letters
>> numpart_hwordPart of hyphenated word, mixed letters and digits
> Is there a ration
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> True. I'll bet you don't like ts_stat() either.
>> It seems the right way interface here wouldn't be too different from what's
>> there. ...
> I'm not sure that's so muc
On Oct 23, 2007, at 10:42 , Tom Lane wrote:
apart_hword Part of hyphenated word, all ASCII letters
part_hword Part of hyphenated word, all letters
numpart_hword Part of hyphenated word, mixed letters and digits
Is there a rationale for using these instead of hword_apart,
hword_pa
I wrote:
> (As an example, "foo-beta1" is a numhword, with component tokens
> "foo" an aword and "beta1" a numword. This is how it works now
> modulo the redefinition of the base categories.)
Argh... need more caffeine. Obviously the component tokens would
be apart_hword and numpart_hword. They
I wrote:
> Maybe "aword", "word", and "numword"?
Does the lack of response mean people are satisfied with that?
Fleshing the proposal out to include the hyphenated-word categories:
aword All ASCII letters
wordAll letters according to iswalpha()
numword Mixed letters
On 10/23/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> Don't *need* would be better.
Forgot to mention I agree. What's done is done. I'm not beating that
UNDO horse anymore; it's long past dead.
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation
Hi,
i am new in this, and i need help with catalog system of postgresql, i need know
how are the relationship between the tables of the system catalog, and how work
each table, if anybody know about this please, answer me.
thank all of you.
---
On 10/23/07, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>
> Ühel kenal päeval, T, 2007-10-23 kell 18:36, kirjutas Gokulakannan
> Somasundaram:
>
> >
> > There are several advantages to keeping a separate visibility
> > heap:
> >
> > 1) it is usually higly compressible, at leas
Ühel kenal päeval, T, 2007-10-23 kell 14:16, kirjutas Heikki
Linnakangas:
> Hannu Krosing wrote:
> > I would suggest that you use just an additional heap with decoupled
> > visibility fields as DSM.
>
> Yeah, I remember you've suggested that before, and I haven't responded
> this far. The problems
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'd suggest we have multiple checkpoints during the cycle. Checkpoint is
> a "patch queue blitz" where we stop developing and reduce the queue to
> nothing. Perhaps a two-week period where everybody helps reduce the
> queue, not just Tom and Bruce. Every ou
Ühel kenal päeval, T, 2007-10-23 kell 18:36, kirjutas Gokulakannan
Somasundaram:
>
> There are several advantages to keeping a separate visibility
> heap:
>
> 1) it is usually higly compressible, at least you can throw
> away
> cmin/cmax q
Hannu Krosing wrote:
> I would suggest that you use just an additional heap with decoupled
> visibility fields as DSM.
Yeah, I remember you've suggested that before, and I haven't responded
this far. The problems I see with that approach are:
1) How do you know which visibility info corresponds w
On 10/23/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> It would be a major mistake to think there's no work left to
> do in improving update performance.
Agreed. That would be a very short-sighted move.
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation
On 10/23/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > We never actually considred undo
>
> I did, but eventually ruled it out during the HOT design process. But
> then I considered a ton of other things and ruled them out also.
>
> Can't see a reason to bring it up again, so perhaps we should add
On 10/23/07, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>
> Ühel kenal päeval, T, 2007-10-23 kell 13:04, kirjutas Heikki
> Linnakangas:
> > Gokulakannan Somasundaram wrote:
> > > Say, with a normal index, you need to goto the table for checking the
> > > snapshot. So you would be loading both the ind
Ühel kenal päeval, T, 2007-10-23 kell 13:04, kirjutas Heikki
Linnakangas:
> Gokulakannan Somasundaram wrote:
> > Say, with a normal index, you need to goto the table for checking the
> > snapshot. So you would be loading both the index pages + table pages, in
> > order to satisfy a certain operatio
On 10/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Gokulakannan Somasundaram wrote:
> > Say, with a normal index, you need to goto the table for checking the
> > snapshot. So you would be loading both the index pages + table pages, in
> > order to satisfy a certain operations. Whereas i
Gokulakannan Somasundaram wrote:
> Say, with a normal index, you need to goto the table for checking the
> snapshot. So you would be loading both the index pages + table pages, in
> order to satisfy a certain operations. Whereas in thick index you occupy 16
> bytes per tuple more in order to avoid
On 10/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Please keep the list cc'd.
>
> Gokulakannan Somasundaram wrote:
> > On 10/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> >> Gokulakannan Somasundaram wrote:
> >> I have also enabled the display of Logical Reads. In order to see
Deblauwe Gino wrote:
> a) I didn't see a reindex in your mail. That's why a backup and a
> restore work and a vacuum doesn't
> http://www.postgresql.org/docs/current/static/sql-reindex.html
> Do this at least daily with that many inserts
>
Hello
I'am sorry to say that this advice does not soun
Please keep the list cc'd.
Gokulakannan Somasundaram wrote:
> On 10/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>> Gokulakannan Somasundaram wrote:
>> I have also enabled the display of Logical Reads. In order to see that,
>> set
>>> log_statement_stats on.
>> You should start benchmarkin
On 10/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Gokulakannan Somasundaram wrote:
> > I would like to present the first patch. It currently has the
> following
> > restrictions
> > a) It does not support any functional indexes.
> > b) It supports queries like select count(1) from
Gokulakannan Somasundaram wrote:
> I would like to present the first patch. It currently has the following
> restrictions
> a) It does not support any functional indexes.
> b) It supports queries like select count(1) from table where (restrictions
> from indexed columns), but it does not suppor
On Mon, 2007-10-22 at 05:13 -0700, Tiago J. Adami wrote:
> Hi all, I'm working for a brazillian company developing and
> maintaining a ERP sw that uses PostgreSQL as it main OLTP database
> system. We're just to start the migration to IBM DB2 because of many
> performance issues. I searched the so
On Mon, 2007-10-22 at 11:00 -0400, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > Josh Berkus wrote:
> > > Bruce Momjian wrote:
> > >> Those who have been with the community from long ago might remember
> > >> discussion about implementing a undo log. The big advantage of this is
> > >> that it
On Mon, 2007-10-22 at 12:37 -0700, Josh Berkus wrote:
> Simon,
>
> > We can issue a provisional date. We could also say "at least 6 months
> > after release date of 8.3". I'm sure there's other options too.
>
> I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short*
> release
On Mon, 2007-10-22 at 23:36 -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Before we settle on any dates I think we should have some discussion
> > about how we can shorten the period between feature freeze and beta,
> > which was far too long this time. Perhaps we need t
On Tue, 2007-10-23 at 11:00 +0200, Rafael Martinez wrote:
> We are always 1 year back the main release. We are testing and planing
> the move to 8.2 now, and it won't happen until desember. In a 6 month
> cycle we will have to jump over every second release.
We here are also just in the process of
Tatsuo Ishii wrote:
>
> +1. Shorter release cycles are maybe good for fancy GUI oriented
> applications, but not so good for DBMS.
> --
I agree, sure it will be great to have even more and new features as
soon as possible, but not if the quality of the final product decrease.
The most important
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I'd rather encourage people to work in an incremental, not-so-big-bang
> fashion. Obviously one of the requirements for that will be quicker
> review turnaround and commit, so that there's time to build on a
> previous patch...
I'll second that. It's awf
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> HOT is cool, but it really doesn't solve the whole problem. It works for a
> significant class of problems, but for example it won't have any significant
> effect on the app I'm currently working on which is very index-rich. It would
> be a major mist
"Tom Lane" <[EMAIL PROTECTED]> writes:
> [ thinks for a bit... ] A truly hard-nosed approach would be to define
> FF as "if your patch isn't committed by the FF date, you lose". The
> FF-to-beta delay then is only long enough to make sure we've documented
> everything, written release notes, etc
> On Mon, 22 Oct 2007, Tom Lane wrote:
>
> > If we want a short FF-to-beta period then the criterion will have to be
> > that patches are either committed or darn near ready to commit on the FF
> > date.
>
> I think you're stuck with a certain amount of schedule delay regardless of
> how matur
> Further the people wanting specific features of a specific release,
> don't have to wait 12-15 months to get them.
>
> I recognize this would be a *lot* easier if we didn't have the initdb
> requirement but still... release early, release often.
>
> I have really taken to the Ubuntu style of rele
On Mon, Oct 22, 2007 at 11:56:02PM -0400, Tom Lane wrote:
> I'd rather encourage people to work in an incremental, not-so-big-bang
> fashion. Obviously one of the requirements for that will be quicker
> review turnaround and commit, so that there's time to build on a
> previous patch...
From my o
2007/10/23, Kevin Grittner <[EMAIL PROTECTED]>:
> >>> On Mon, Oct 22, 2007 at 4:37 PM, in message
> <[EMAIL PROTECTED]>, "Kevin Grittner"
> <[EMAIL PROTECTED]> wrote:
>
> > One more logically equivalent, PostgreSQL-specific form which
> > costs out even better was suggested off-list:
>
> Oops. Th
Ühel kenal päeval, L, 2007-10-20 kell 10:19, kirjutas Luke Lonergan:
> Hi Hannu,
>
> On 10/14/07 12:58 AM, "Hannu Krosing" <[EMAIL PROTECTED]> wrote:
>
> > What has happened in reality, is that the speed difference between CPU,
> > RAM and disk speeds has _increased_ tremendously
>
> Yes.
>
> >
93 matches
Mail list logo
