From: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
---|---|
To: | Sean Chittenden <sean(at)chittenden(dot)org> |
Cc: | pgsql-advocacy(at)postgresql(dot)org |
Subject: | Re: 7.4 Press Release -- Draft #3 |
Date: | 2003-07-22 13:12:11 |
Message-ID: | 1058879531.22259.199.camel@camel |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
On Mon, 2003-07-21 at 19:40, Sean Chittenden wrote:
<snip>
> >
> > - A redesign of subquery handling with the IN() clause resulting
> > in considerable speed improvements.
>
> Might be worth while mentioning something like the following to go
> with the above point:
>
> Other additional planner improvements have brought PostgreSQL's
> performance inline with the large RDBMS vendors.
>
Improvements to the query planner, including a redesign of subquery
handling with the IN() clause, resulting in considerable speed
improvements.
<snip>
>
> How about "Explicit JOINs no longer constrain query plan, unless
> JOIN_COLLAPSE_LIMIT = 1"? This is kind of a big deal for MS SQL
> users/organizations.. Targeting their audience would be good and
> increase our user uptake from their dept.
>
> When enabled, the planner can now automatically optimize the
> join order of queries: a feature found in a few commercial
> RDBMS's that can reduce the time busy DBAs need to spend
> optimizing queries.
>
I don't like this because the planner already optimizes the join order
of queries for non explicit joins, and to me I have always looked at the
ability to ability to constrain query plans based on join order as
feature...
Josh wrote:
> Optional explicit join rewriting by the query planner,
> allowing an easy transition for MS SQL Server users.
I don't like that, because istm win32 would really make transition
easier, and I'd like to avoid bringing up thoughts of that...
Are there other databases that use this behavior?
>
> Mentioning the protocol change is also probably important here.
>
> New wire protocol (version 3) increases the speed of data transfers.
>
> I haven't benchmarked it, but from what I've read of the protocol
> spec, it likely does. Tom might want to confirm this. More efficient
> BYTEA transfers is a big deal for the medical community that's storing
> MRIs in PostgreSQL.
>
If you can get Tom to confirm this, I would put it in.
> Mentioning support for AMD's Opteron would also be a good bit to have
> since that says, "we're a safe database to base your business around
> because we move with the times and support cutting edge hardware, even
> though the project has been around forever."
>
still thinking on this one... it's not new that we support 64bit
hardware.
>
> > 3. Need a URL for the changelog
>
> http://www.postgresql.org/docs/7.4static/release.html#RELEASE-7-4
>
I've proffered http://www.postgresql.org/docs/release/740.html to the
web group, which seems to have been found acceptable (at least no one
objected). Anyone want to create pages for all of the previous releases?
>
> Sorry for putting on my editor hat so late in the announcement
> drafting process. -sc
>
No problem, you've got some good suggestions here.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
From | Date | Subject | |
---|---|---|---|
Next Message | greg | 2003-07-22 13:25:34 | Re: 7.4 Press Release -- Draft #3 |
Previous Message | Robert Treat | 2003-07-22 12:41:33 | Re: 7.4 Press Release -- Draft #3 |