Subject: Re: Updated documentation for new sequence binding

From: Bruce Momjian <[email-masked]>
Date: Sun, 2 Oct 2005 22:54:10 -0400 (EDT)

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

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

---

From: "Michael Paesold" <[email-masked]>
Date: Mon, 3 Oct 2005 08:23:56 +0200

> http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1

Btw. I think the header "Add proper sequence function dependencies for 
DEFAULT" is in the wrong font, i.e. it's all monospace.

Best Regards
Michael Paesold

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 3 Oct 2005 09:52:19 -0400 (EDT)

Thanks, fixed.

---------------------------------------------------------------------------

Michael Paesold wrote:
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org
>

---

From: "Jim C. Nasby" <[email-masked]>
Date: Wed, 5 Oct 2005 13:58:53 -0500

> 	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...

That said, what's

 Improve the optimizer, including auto-resizing of hash joins (Tom)

mean?

On full_page_writes, are we certain that all battery-backed disk caches
ensure that partial-page writes can't happen?

Maybe pg_column_size 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...

Finally, weren't more changes made it contrib than what's listed?
Nothing's said about pg_autovacuum for example.
-- 
Jim C. Nasby, Sr. Engineering Consultant      [email-masked]
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 5 Oct 2005 15:52:44 -0400 (EDT)

> waiting for the end. Even a link to a mailing list discussion would be

I go through the CVS commits and make the release notes just before
beta.  During it incrementally is much more work.

>  Improve the optimizer, including auto-resizing of hash joins (Tom)

We would sometimes fail in a query where the allocated memory was larger
than our hash could hold.  This fixed that.

> 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

Not really.  It is different in that is does not aggregate values, but
just the storage of a column.

> Nothing's said about pg_autovacuum for example.

Moved to the main server.  That is mentioned.