Re: [PATCHES] Interval input: usec, msec

2007-05-29 Thread Michael Glaesemann
On May 29, 2007, at 0:06 , Neil Conway wrote: Applied to HEAD, backported to 8.2 and 8.1 One thing I noticed when looking over the patch is that there are a few bare numbers in datetime.c such as 10, 1000, 1e-3, and 1e-6. In timestamp.[hc] we've defined macros for conversions such as

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-05-29 Thread Zdenek Kotala
Pavan Deolasee wrote: On 1/28/07, *Tom Lane* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: OTOH it might be cleaner to refactor things that way, if we were going to apply this. Here is a revised patch which includes refactoring of heap_get_latest_tid(), as per Tom's suggestion.

Re: [PATCHES] Seq scans status update

2007-05-29 Thread Alvaro Herrera
Tom Lane wrote: Gregory Stark [EMAIL PROTECTED] writes: Is there a reason UnpinBuffer has to be the one to increment the usage count anyways? Why can't ReadBuffer handle incrementing the count and just trust that it won't be decremented until the buffer is unpinned anyways? That's a good

Re: [PATCHES] Concurrent psql patch

2007-05-29 Thread Gregory Stark
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: if (pset.c-db-asyncStatus != PGASYNC_BUSY) { break; } There already is a defined API for this, namely PQisBusy(). Oh, now I remember why

Re: [PATCHES] Concurrent psql patch

2007-05-29 Thread Gregory Stark
Tom Lane [EMAIL PROTECTED] writes: Andrew Dunstan [EMAIL PROTECTED] writes: if (pset.c-db-asyncStatus != PGASYNC_BUSY) { break; } There already is a defined API for this, namely PQisBusy(). In any case, I rather concur with the XXX

Re: [PATCHES] Seq scans status update

2007-05-29 Thread Heikki Linnakangas
Alvaro Herrera wrote: Tom Lane wrote: Gregory Stark [EMAIL PROTECTED] writes: Is there a reason UnpinBuffer has to be the one to increment the usage count anyways? Why can't ReadBuffer handle incrementing the count and just trust that it won't be decremented until the buffer is unpinned

[PATCHES] WIP: 2nd-generation buffer ring patch

2007-05-29 Thread Tom Lane
Updated version of Heikki's buffer ring patch, as per my comments here: http://archives.postgresql.org/pgsql-patches/2007-05/msg00449.php The COPY IN part of the patch is not there, pending resolution of whether we think it adds enough value to be worth uglifying heap_insert's API for. Also, I

Re: [PATCHES] Logging checkpoints and other slowdown causes

2007-05-29 Thread Heikki Linnakangas
Greg Smith wrote: I'll take another stab at refining this can of worms I opened. The one thing I noticed on a quick review is that it's almost possible to skip all the calls to gettimeofday if log_checkpoints is off now. I'd like to make that a specific goal, because that will make me feel

Re: [PATCHES] WIP: 2nd-generation buffer ring patch

2007-05-29 Thread Heikki Linnakangas
Tom Lane wrote: Also, I tentatively reduced the threshold at which heapscans switch to ring mode to NBuffers/16; that probably needs more thought. Yeah. One scenario where threshold shared_buffers will hurt is if your shared_buffers = RAM size / 2. In that scenario, a scan on a table that

[PATCHES] OS X startup script patch

2007-05-29 Thread Les Hill
Hi, I recently built and installed postgres 8.2.4 on my MBP (10.4.9). Thanks for the great work! The existing startup script worked with one tweak, the rotate logs command was not redirecting stderr to the log. A patch generated with the make_diff scripts is attached. -- Les Hill [EMAIL

Re: [PATCHES] WIP: 2nd-generation buffer ring patch

2007-05-29 Thread Tom Lane
Heikki Linnakangas [EMAIL PROTECTED] writes: Also there's no attempt to not inflate usage_count, which means that synchronized scans will spoil the buffer cache as if we didn't have the buffer ring patch. As I said, these patches are hardly independent. If there's no easy solution, I think

[PATCHES] Regression tests

2007-05-29 Thread Magnus Hagander
Joachim Wieland attempted to post this patch, but it appears to be gone. I tried a repost, and notivced it got rejected because it was 100kb. Let me repeat previous objections that it really should be possible to post a patch 100kb. That said, here's a gzipped version. Joachim, once it comes

Re: [PATCHES] WIP: 2nd-generation buffer ring patch

2007-05-29 Thread Tom Lane
I wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: If there's no easy solution, I think we could live with that, but Greg's suggestion of bumping the usage_count in PinBuffer instead of UnpinBuffer sounds like a nice solution to me. After thinking about it more, I'm a bit hesitant to do

Re: [PATCHES] Regression tests

2007-05-29 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes: Joachim Wieland attempted to post this patch, but it appears to be gone. I trust the applied version will contain neither Windows newlines nor non-English comments. regards, tom lane ---(end of

Re: [PATCHES] Seq scans status update

2007-05-29 Thread Jeff Davis
On Mon, 2007-05-28 at 17:36 -0400, Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: One idea is to keep track which pins are taken using the bulk strategy. It's a bit tricky when a buffer is pinned multiple times since we don't know which ReleaseBuffer corresponds which

Re: [PATCHES] WIP: 2nd-generation buffer ring patch

2007-05-29 Thread Greg Smith
On Tue, 29 May 2007, Tom Lane wrote: Do we have any decent way of measuring the effectiveness of the clock-sweep allocation algorithm? I put a view on top of the current pg_buffercache (now that it include usage_count) that shows what the high usage_count buffers consist of. Since they were

Re: [PATCHES] WIP: 2nd-generation buffer ring patch

2007-05-29 Thread Tom Lane
Greg Smith [EMAIL PROTECTED] writes: Based on my observations of buffer cache statistics, the number of pinned buffers at any time is small enough that in a reasonably sized buffer cache, I wouldn't expect a change in the pinned usage_count behavior to have any serious impact. Fair enough.

Re: [PATCHES] Logging checkpoints and other slowdown causes

2007-05-29 Thread Greg Smith
On Tue, 29 May 2007, Heikki Linnakangas wrote: The checkpoint will take at least a couple of seconds on any interesting system, so 0.1 s resolution should be enough IMHO. You may be underestimating the resources some interesting systems are willing to put into speeding up checkpoints. I'm