From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL-documentation <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: Updated documentation for new sequence binding |
Date: | 2005-10-05 19:52:44 |
Message-ID: | 200510051952.j95JqiQ16533@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
Jim C. Nasby wrote:
> On Sun, Oct 02, 2005 at 10:54:10PM -0400, Bruce Momjian wrote:
> > pgman wrote:
> > > I have marged Tom's description of the new sequence binding with text I
> > > was working on. I modified it to follow the existing "we used to do X,
> > > now we do Y" pattern in the surrounding entries:
> > >
> > > http://candle.pha.pa.us/tmp/pgsql/release.html#RELEASE-8-1
> >
> > Sorry, this is a better URL:
> >
> > http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1
>
> Out of curiosity, how is this file maintained as development is done?
> The reason I'm asking is because it would be nice to have links to more
> information, especially for the 'one-liner' items in 1.3.1 for example,
> and it seems like that would be easier to do along-the-way rather than
> waiting for the end. Even a link to a mailing list discussion would be
> better than nothing...
I go through the CVS commits and make the release notes just before
beta. During it incrementally is much more work.
> That said, what's
>
> Improve the optimizer, including auto-resizing of hash joins (Tom)
>
> mean?
We would sometimes fail in a query where the allocated memory was larger
than our hash could hold. This fixed that.
>
> On full_page_writes, are we certain that all battery-backed disk caches
> ensure that partial-page writes can't happen?
Well, I would think so, but I have no documentation to state that. The
battery-backed memory is supposed to allow for power failure and keep
writes in the cache until they hit the disk.
> Maybe pg_column_siz should just be included in the item for all the
> other size functions brought into the backend? If not, ISTM they should
> at least be one after the other in the list...
Not really. It is different in that is does not aggregate values, but
just the storage of a column.
> Finally, weren't more changes made it contrib than what's listed?
> Nothing's said about pg_autovacuum for example.
Moved to the main server. That is mentioned.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Rodrigues | 2005-10-05 20:47:18 | Online comments system |
Previous Message | Jim C. Nasby | 2005-10-05 19:45:28 | Re: XML and PostGreSql |
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2005-10-05 19:54:42 | Re: [PERFORM] A Better External Sort? |
Previous Message | Tom Lane | 2005-10-05 19:51:17 | Re: [jnasby@pervasive.com: [BUGS] Race condition in dropdb; createdb] |