Re: 7.4 Press Release -- Draft #3 - Mailing list pgsql-advocacy
From | Robert Treat |
---|---|
Subject | Re: 7.4 Press Release -- Draft #3 |
Date | |
Msg-id | 1058879531.22259.199.camel@camel Whole thread Raw |
In response to | Re: 7.4 Press Release -- Draft #3 (Sean Chittenden <sean@chittenden.org>) |
Responses |
Re: 7.4 Press Release -- Draft #3
|
List | 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
pgsql-advocacy by date: