Re: [PATCHES] Have vacuum emit a warning when it runs out of maintenance_work_mem

2007-05-12 Thread Jim C. Nasby
On Fri, May 11, 2007 at 10:18:30PM -0400, Robert Treat wrote: > On Wednesday 09 May 2007 19:41, Guillaume Smet wrote: > > On 5/9/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > > Jim Nasby <[EMAIL PROTECTED]> writes: > > > > Any time this happens it's generally a nasty surprise for users. > > > > > > R

Re: [PATCHES] Preliminary GSSAPI Patches

2007-05-12 Thread Henry B. Hotz
These patches are updated as discussed to remove the incomplete feature. Unfortunately I have a wedding to go to this weekend and won't get them tested until next week. Will post when I've done so. On Mar 31, 2007, at 3:41 PM, Henry B. Hotz wrote: These patches have been reasonably tested

Re: [PATCHES] Have vacuum emit a warning when it runs out of maintenance_work_mem

2007-05-12 Thread Heikki Linnakangas
Or we could switch to a more compact representation of the dead tuples, and not need such a big maintenance_work_mem in the first place. Jim C. Nasby wrote: On Fri, May 11, 2007 at 10:18:30PM -0400, Robert Treat wrote: On Wednesday 09 May 2007 19:41, Guillaume Smet wrote: On 5/9/07, Tom Lane

Re: [PATCHES] Have vacuum emit a warning when it runs out of maintenance_work_mem

2007-05-12 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Or we could switch to a more compact representation of the dead tuples, > and not need such a big maintenance_work_mem in the first place. Hm, you got any ideas? One constraint is that it doesn't seem acceptable to make the search function any slo

Re: [PATCHES] Have vacuum emit a warning when it runs out of maintenance_work_mem

2007-05-12 Thread Jim C. Nasby
On Sat, May 12, 2007 at 07:57:44PM +0100, Heikki Linnakangas wrote: > Or we could switch to a more compact representation of the dead tuples, > and not need such a big maintenance_work_mem in the first place. Sure, but even with a more compact representation you can still run out of maintenance_w

Performance monitoring (was: [PATCHES] Logging checkpoints and other slowdown causes)

2007-05-12 Thread Jim C. Nasby
Moving to -hackers. On Fri, May 11, 2007 at 04:37:44PM +0100, Heikki Linnakangas wrote: > >If you know when the checkpoint ended, and you know how long each of the > >pieces took, you can reconstruct the other times easily. The way you > >describe this it is true--that the summary is redundant

Re: [PATCHES] Concurrent psql patch

2007-05-12 Thread Jim Nasby
On May 11, 2007, at 10:55 AM, Gregory Stark wrote: Also, if anyone has any better ideas for names than \cswitch and \cnowait now's the time. I had intended them only as placeholders because I couldn't think of anything better but it doesn't sound like anyone else has any better ideas either.

Re: [PATCHES] Enable integer datetimes by default

2007-05-12 Thread Bruce Momjian
Added to TODO: * Have configure choose integer datetimes by default http://archives.postgresql.org/pgsql-patches/2007-05/msg00046.php --- Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > On Sun, 2007-06-05

Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages

2007-05-12 Thread Greg Smith
Attached are two patches that try to recast the ideas of Itagaki Takahiro's auto bgwriter_lru_maxpages patch in the direction I think this code needs to move. Epic-length commentary follows. The original code came from before there was a pg_stat_bgwriter. The first patch (buf-alloc-stats) ta