SEO

I'm not clear on why there's all this doom and gloom about how 8.2 will
be "merely" a performance-oriented release, with few new features, eg
http://archives.postgresql.org/pgsql...7/msg00111.php

Certainly there's been a ton of effort spent on high-end performance
issues. But a quick troll through the CVS logs shows a fair number of
features that could be considered killer must-have things by their
respective target audiences:

multi-row VALUES, not only for INSERT but everywhere SELECT is allowed
pg_dump multiple -n and -t options, regex patterns for object names
multi-argument aggregates, including SQL2003-standard statistical aggregates
fully configurable timezone abbreviations (no more 'australian_timezones' hack)
allow full zic timezone names in datetime input values
support comparisons like "if row(new.*) is distinct from row(old.*)"
DROP ... IF EXISTS
numerous tsearch2 improvements, eg thesaurus
GIN index opclass
GRANT CONNECT ON DATABASE
support SSL Certificate Revocation List (CRL) files
plpython supports named parameters, composite-type results, more result-set options
plperl prepared queries
domain constraint checks are now applied everywhere
better psql multiline command handling
error cursor position displayed for many parse-analysis errors
standard_conforming_strings can be turned on (HUGE deal for some people)
initdb and pg_ctl can safely start from an admin account on Windows
display multiline values nicely in psql
support SQL-compliant row comparisons; they can be indexscan quals
DROP OWNED, REASSIGN OWNED for dealing with removal of a user
null elements in arrays

There are also some commits that are "mere" performance tweaks, and yet
we should not understate their importance because they could make the
difference between usability and non-usability in many applications:

lazy vacuums are ignored by other processes; improves behavior of concurrent vacuums
add index and table storage options (currently only FILLFACTOR)
stats_command_string overhead reduced to near zero, now on by default
reduce locking involved in DATABASE commands, eg CREATE DATABASE no longer blocks incoming connections
constraint exclusion works for UPDATE and DELETE
constraint exclusion works for UNION ALL views, not only inheritance trees
planner can rearrange join order for many common OUTER JOIN scenarios

And that's not counting some pretty significant submitted-but-not-yet-
reviewed patches (sure, some of these may get rejected, but they're all
open possibilities today):

online index builds
bitmap index AM
updatable views
PL plugin patch (plpgsql debugger infrastructure)
restartable recovery (allow checkpoints for a hot-standby server)
INSERT/UPDATE RETURNING

Not that there's anything wrong with a performance-oriented release
.... but if you think that 8.2 is short on features, you'd better get
ready to be disappointed by every future release. There's not all
that much stuff left to do in terms of raw language "features".
(Of course the SQL committee keeps inventing a ton of new stuff every
few years, but how much of that do you really care about?)

regards, tom lane

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

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

Tom Lane wrote:

>Not that there's anything wrong with a performance-oriented release
>... but if you think that 8.2 is short on features, you'd better get
>ready to be disappointed by every future release.
>

It's a pity that some expectations have been raised about features that
we haven't seen patches for, e.g. MERGE and/or some form of UPSERT, and
recursive queries. I am not pointing fingers, but I do think we need
some way in which the community can ensure that certain goals are met,
or at least try to help if things fall in a ditch, rather than just
relying on hackers scratching whatever itch they happen to get in
splendid isolation and then trying to merge the results.

cheers

andrew

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

On 8/4/06, Andrew Dunstan <andrew@dunslane.net> wrote:
> It's a pity that some expectations have been raised about features that
> we haven't seen patches for, MERGE/UPSERT & recursive queries

Honestly, I've only had four people say it would be nice to have
hierarchical queries (one of them wasn't even a PostgreSQL user).
Almost everyone else seems to ask some variation of, "what's a
hierarchical query and why do I need it?" It's hard to get excited
about writing a patch no one sees a real need for.

When I have a choice of working on things in my spare time, I choose
what to work on based on basically two things (a) what is my interest
in it and (b) who is going to use it. Based on that, I determine
whether it's worth going through the hassle of design, development,
testing, and final documentation (my prelim docs come from design).

In short, I know a lot of people would probably use this feature after
it was there, but *very* few have shown any interest in it and a patch
for it (while in need of rewriting) has existed since 7.4.

> I am not pointing fingers, but I do think we need
> some way in which the community can ensure
> that certain goals are met, or at least try to help
> if things fall in a ditch, rather than just relying on
> hackers scratching whatever itch they happen to
> get in splendid isolation and then trying to merge
> the results.

I agree. The real problem is that we don't look at things in a
business-like, "what are we going to have in the next release"
perspective. Being as it's an OSS community, we just see what patches
come in and we apply what we choose... then pick which ones we see as
"major features" and announce them.

I'd like to be mistaken here, but I don't think we've ever really had
release planning in regards to features. We can always sit down after
8.2 is finalized and plan what are we doing for 8.3 and go from there.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

---------------------------(end of broadcast)---------------------------
TIP 1: 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

Jonah H. Harris wrote:

> On 8/4/06, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>> It's a pity that some expectations have been raised about features that
>> we haven't seen patches for, MERGE/UPSERT & recursive queries
>
>
> Honestly, I've only had four people say it would be nice to have
> hierarchical queries (one of them wasn't even a PostgreSQL user).
> Almost everyone else seems to ask some variation of, "what's a
> hierarchical query and why do I need it?" It's hard to get excited
> about writing a patch no one sees a real need for.
>
> When I have a choice of working on things in my spare time, I choose
> what to work on based on basically two things (a) what is my interest
> in it and (b) who is going to use it. Based on that, I determine
> whether it's worth going through the hassle of design, development,
> testing, and final documentation (my prelim docs come from design).
>
> In short, I know a lot of people would probably use this feature after
> it was there, but *very* few have shown any interest in it and a patch
> for it (while in need of rewriting) has existed since 7.4.
>

Chicken vs. egg. Look at the number of people using nested sets and
other similar abominations to handle hierarchical data. There are whole
books written about using these kludgy techniques. I think this really
is a case of "build it and they will come".

cheers

andrew



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

On 8/3/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm not clear on why there's all this doom and gloom about how 8.2 will
> be "merely" a performance-oriented release, with few new features, eg
> http://archives.postgresql.org/pgsql...7/msg00111.php
>
> Certainly there's been a ton of effort spent on high-end performance
> issues. But a quick troll through the CVS logs shows a fair number of
> features that could be considered killer must-have things by their
> respective target audiences:

i can't resist this unproductive distraction from actual work. this
is a huge release for me as it nails a lot of the features i've been
waiting literally years for. it feels a lot like the 7.4 release
where similar debates when on esp. regarding the windows port, etc.

note that even if the release had no user level features at all, it
would be better to release: the outside world likes to see the project
is still active and moving forward.

merlin

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

On Fri, Aug 04, 2006 at 09:37:32AM -0400, Jonah H. Harris wrote:
> I agree. The real problem is that we don't look at things in a
> business-like, "what are we going to have in the next release"
> perspective. Being as it's an OSS community, we just see what patches
> come in and we apply what we choose... then pick which ones we see as
> "major features" and announce them.

There's a fairly standard way of getting people to do things for you:
pay them money. Thing is, people can run around making lists of thing
that would be cool, but no-one can really force anyone to do anything.

Now, there are the priveledged few who are being paid to work on
postgres. If you can convince their employers to fund things on the
list, it might help. Also, some stuff might work well as Google SoC
projects...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFE016CIB7bNG8LQkwRAsQsAJ9gwkPXoApGRQzY63SP1j f4lNKtAQCgj+By
fFhIcqPUdRJHIaTv4Sg/8qY=
=qiBs
-----END PGP SIGNATURE-----

Jonah H. Harris wrote:
> On 8/4/06, Andrew Dunstan <andrew@dunslane.net> wrote:
>> It's a pity that some expectations have been raised about features that
>> we haven't seen patches for, MERGE/UPSERT & recursive queries
>
> Honestly, I've only had four people say it would be nice to have
> hierarchical queries (one of them wasn't even a PostgreSQL user).

You obviously aren't dealing with the number of people I am I get
this question all the time.

> I agree. The real problem is that we don't look at things in a
> business-like, "what are we going to have in the next release"
> perspective. Being as it's an OSS community, we just see what patches
> come in and we apply what we choose... then pick which ones we see as
> "major features" and announce them.
>
> I'd like to be mistaken here, but I don't think we've ever really had
> release planning in regards to features. We can always sit down after
> 8.2 is finalized and plan what are we doing for 8.3 and go from there.

The only way we will get even a reasonable about of release planning is
for the commercial entities involved around PostgreSQL to put a lot more
resources into actually developing PostgreSQL.

Joshua D. Drake



--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/



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

On Friday 04 August 2006 09:37, Jonah H. Harris wrote:
> On 8/4/06, Andrew Dunstan <andrew@dunslane.net> wrote:
> > It's a pity that some expectations have been raised about features that
> > we haven't seen patches for, MERGE/UPSERT & recursive queries
>
> Honestly, I've only had four people say it would be nice to have
> hierarchical queries (one of them wasn't even a PostgreSQL user).
> Almost everyone else seems to ask some variation of, "what's a
> hierarchical query and why do I need it?" *It's hard to get excited
> about writing a patch no one sees a real need for.

Make that five. I'll bless the day I can get rid of my recursive plsql
functions.

jan

--
--------------------------------------------------------------
Jan de Visser * * * * * * * * * * jdevisser@digitalfairway.com

* * * * * * * * Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

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

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

Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >Not that there's anything wrong with a performance-oriented release
> >... but if you think that 8.2 is short on features, you'd better get
> >ready to be disappointed by every future release.
> >
>
> It's a pity that some expectations have been raised about features that
> we haven't seen patches for, e.g. MERGE and/or some form of UPSERT, and
> recursive queries. I am not pointing fingers, but I do think we need
> some way in which the community can ensure that certain goals are met,
> or at least try to help if things fall in a ditch, rather than just
> relying on hackers scratching whatever itch they happen to get in
> splendid isolation and then trying to merge the results.

What we do is when people claim items, we monitor them to be sure they
get them done for the current release, or at least give it their best
try. There is not much more we can do.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 1: 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

Merlin Moncure wrote:
> On 8/3/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not clear on why there's all this doom and gloom about how 8.2 will
>> be "merely" a performance-oriented release, with few new features, eg
>> http://archives.postgresql.org/pgsql...7/msg00111.php
>>
>> Certainly there's been a ton of effort spent on high-end performance
>> issues. But a quick troll through the CVS logs shows a fair number of
>> features that could be considered killer must-have things by their
>> respective target audiences:
>
> i can't resist this unproductive distraction from actual work. this
> is a huge release for me as it nails a lot of the features i've been
> waiting literally years for. it feels a lot like the 7.4 release
> where similar debates when on esp. regarding the windows port, etc.
>
> note that even if the release had no user level features at all, it
> would be better to release: the outside world likes to see the project
> is still active and moving forward.


I fully agree here - 8.2 is a release that is of more interest to us
than say 8.0 was.
For some of our existing apps 8.2 is dramatically faster due to much
better planed queries and things like 20-25% faster dump/restore cycles
due to the dramatic improvements on sorting (and therefor CREATE INDEX)
are really really cool things.
Just switching to 8.2 makes one of our (interactive-web) app feel
"blazingly fast" instead of just "ok" and that is a good thing - a very
good one in fact ...
And beside that the list tom posted is already damn impressive on it's
own - i guess there are a number of large projects that can only dream
of having a "new features" list like that.


Stefan

---------------------------(end of broadcast)---------------------------
TIP 1: 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