You might remember that when we released 8.0, the plan was to have a
12-month development cycle for 8.1, unless there were Win32 problems
that required complex fixes, in which case we would have a shorter 8.1
cycle.

Well the good news is that there have been almost no Win32 problems, but
the other good news is that we are getting a lot of powerful features
for 8.1 already:

o two-phase (Heikki Linnakangas, almost done)
o multiple out function paramters (Tom, done)
o bitmappted indexes (Tom, almost done)
o shared row locks (Alvaro, almost done)
o integrated auto-vacuum (Bruce)
o buffer cache fixes for SMP (Tom, done)

It is possible all these items will be done by sometime in June. Now,
if that happens, do we want to continue with the 12-month plan or
shorten the 8.1 release cycle, perhaps targeting a release in the
September/October timeframe?

The current core proposal is to do feature freeze on July 1, with the
understanding that we will be done most of the items above by then and
have the outstanding patches applied.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Thu, Apr 28, 2005 at 09:02:40 -0400,
Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> Well the good news is that there have been almost no Win32 problems, but
> the other good news is that we are getting a lot of powerful features
> for 8.1 already:

You forgot to list the indexed aggregate feature for max and min. While
this isn't that important for experienced postgres users, it is a gotcha
for new users. Between this, integrated autovacuum and the cross type
index changes in 8.0 we have covered almost all of the newbie gotchas.
This should make Postgres effectively equivalent in difficulty with
getting started for new users as MySQL. That could significantly
boost usage for low end use once word gets out.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Bruce Momjian wrote:
> You might remember that when we released 8.0, the plan was to have a
> 12-month development cycle for 8.1, unless there were Win32 problems
> that required complex fixes, in which case we would have a shorter 8.1
> cycle.
>
> Well the good news is that there have been almost no Win32 problems, but
> the other good news is that we are getting a lot of powerful features
> for 8.1 already:
>
> o two-phase (Heikki Linnakangas, almost done)
> o multiple out function paramters (Tom, done)
> o bitmappted indexes (Tom, almost done)
> o shared row locks (Alvaro, almost done)
> o integrated auto-vacuum (Bruce)
> o buffer cache fixes for SMP (Tom, done)
>
> It is possible all these items will be done by sometime in June. Now,
> if that happens, do we want to continue with the 12-month plan or
> shorten the 8.1 release cycle, perhaps targeting a release in the
> September/October timeframe?
>
> The current core proposal is to do feature freeze on July 1, with the
> understanding that we will be done most of the items above by then and
> have the outstanding patches applied.

It seems to be a good idea to take the chance now to make a release.
Delaying the release would mean preventing the wide usage of features
although they appear production grade. OTOH, if feature freeze is
delayed some seemingly essential features for 8.1 which might arise in
the meantime might delay the release further, or induce late feature
exclusion when some last minute issues are discovered. Integrated
autovacuum seems good enough a reason to release early.

Regards,
Andreas


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> o integrated auto-vacuum (Bruce)

If this can kick off a vacuum of a Very Large Table at an unfortunate
time, this can turn out to be a prety painful misfeature.

What I'd _really_ love to see (and alas, it's beyond my ken) is some
parallel to the FSM, namely a "Recently Updated Blocks Map," which
would enable a vacuuming approach that would not go through entire
tables, but which would rather go through only those blocks known to
be recently updated.

There continues to be trouble if you have a table that grows to 50
million rows where there are 100K rows that are being heavily
updated. In effect, only the 100K rows need facuuming.
--
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://linuxfinances.info/info/emacs.html
Group Dynamics
"Following Minsky and Schelling, consider a person as a society of
agents. A group is then a larger society of such agents. Understand
groups by examining interactions of coalitions of agents that
cross-cut their grouping into people."
-- Mark Miller

Christopher Browne <cbbrowne@acm.org> writes:
> In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
>> o integrated auto-vacuum (Bruce)

> If this can kick off a vacuum of a Very Large Table at an unfortunate
> time, this can turn out to be a prety painful misfeature.

[ shrug... ] You'll always be able to turn it off if you don't want it.
I'm not sure that we'll be ready to turn it on by default even in 8.1.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Tom Lane wrote:
> Christopher Browne <cbbrowne@acm.org> writes:
> > In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> >> o integrated auto-vacuum (Bruce)
>
> > If this can kick off a vacuum of a Very Large Table at an unfortunate
> > time, this can turn out to be a prety painful misfeature.
>
> [ shrug... ] You'll always be able to turn it off if you don't want it.
> I'm not sure that we'll be ready to turn it on by default even in 8.1.

Agreed. It will just be there to turn on from postgresql.conf if you
want it, and we do have TODO information about keeping such an FSM for
recently expired pages.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Fri, Apr 29, 2005 at 10:09:43 -0400,
Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> Tom Lane wrote:
> > Christopher Browne <cbbrowne@acm.org> writes:
> > > In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> > >> o integrated auto-vacuum (Bruce)
> >
> > > If this can kick off a vacuum of a Very Large Table at an unfortunate
> > > time, this can turn out to be a prety painful misfeature.
> >
> > [ shrug... ] You'll always be able to turn it off if you don't want it.
> > I'm not sure that we'll be ready to turn it on by default even in 8.1.
>
> Agreed. It will just be there to turn on from postgresql.conf if you
> want it, and we do have TODO information about keeping such an FSM for
> recently expired pages.

I think if we aren't finding problems in testing that it would be better
to turn pg_autovacuum on by default. Vacuum is something the burns new
users and having it one by default is going to cut down on surprises.
Experienced users know about vacuum and will probably read the release
notes when upgrading and do something that is appropiate for them.

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane wrote:

>Christopher Browne <cbbrowne@acm.org> writes:
>
>
>>If this can kick off a vacuum of a Very Large Table at an unfortunate
>>time, this can turn out to be a prety painful misfeature.
>>
>>
>
>[ shrug... ] You'll always be able to turn it off if you don't want it.
>I'm not sure that we'll be ready to turn it on by default even in 8.1.
>
>

What to people think about having an optional "maintenance window" so
that autovac only takes action during an approved time. But perhaps
just using the vacuum delay settings will be enough.


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Fri, 29 Apr 2005, Bruno Wolff III wrote:

> On Fri, Apr 29, 2005 at 10:09:43 -0400,
> Bruce Momjian <pgman@candle.pha.pa.us> wrote:
>> Tom Lane wrote:
>>> Christopher Browne <cbbrowne@acm.org> writes:
>>>> In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
>>>>> o integrated auto-vacuum (Bruce)
>>>
>>>> If this can kick off a vacuum of a Very Large Table at an unfortunate
>>>> time, this can turn out to be a prety painful misfeature.
>>>
>>> [ shrug... ] You'll always be able to turn it off if you don't want it.
>>> I'm not sure that we'll be ready to turn it on by default even in 8.1.
>>
>> Agreed. It will just be there to turn on from postgresql.conf if you
>> want it, and we do have TODO information about keeping such an FSM for
>> recently expired pages.
>
> I think if we aren't finding problems in testing that it would be better
> to turn pg_autovacuum on by default. Vacuum is something the burns new
> users and having it one by default is going to cut down on surprises.

Except for the surprise of peridically having the system go unresponsive
because it hit a large table, and that new user wondering what is wrong
with postgresql that it just stalls seemingly randomly

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

On Fri, Apr 29, 2005 at 12:43:37 -0300,
"Marc G. Fournier" <scrappy@postgresql.org> wrote:
> On Fri, 29 Apr 2005, Bruno Wolff III wrote:
>
> Except for the surprise of peridically having the system go unresponsive
> because it hit a large table, and that new user wondering what is wrong
> with postgresql that it just stalls seemingly randomly

I think most users running systems with that large of tables will know
what they are doing. And will be more careful with vacuum.

Vacuum running for a long time on large tables with few pages that need
updating is really a separate problem that could use its own solution.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org