Re: [PATCHES] variadic function support

opinion, but allowing zero-argument variadic function calls -- and therefore causing foo(variadic int[]) and foo(variadic text[]) to conflict -- makes more sense than requiring one argument. It also seems a little more natural from a function author's perspective. Regards, Jeff Davis -- Sent

Re: [PATCHES] variadic function support

with no arguments. I mentioned that in my other email, but it applies to v2.2.1 as well. And we should come to a consensus quickly about the declaration style, e.g. variadic int[] or variadic int. Regards, Jeff Davis -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org

Re: [PATCHES] variadic function support

On Sat, 2008-07-12 at 23:06 -0700, Jeff Davis wrote: I don't have a strong opinion about whether the variadic argument is declared as an array or scalar, so I am posting my comments about this version of the patch as well. This version also has a problem when declaring two functions foo(int

[PATCHES] synchronized scan: reset state at end of scan

in the attached patch. I do not have a strong opinion about whether this patch is applied or not. I am submitting this just for the sake of completeness. Regards, Jeff Davis diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c index c1afff3..b5bf780 100644 --- a/src

Re: [PATCHES] synchronized scan: reset state at end of scan

) partially masking the order-nondeterminism created by syncscans would be a bad thing because it would make it more likely for people to not notice the issue during testing. Ok, I certainly am not pushing for this patch to be applied. I'll consider it closed. Regards, Jeff Davis -- Sent via

[PATCHES] Doc patch: type modifiers

(for the sake of symmetry). Patch attached. Regards, Jeff Davis diff --git a/doc/src/sgml/ref/create_type.sgml b/doc/src/sgml/ref/create_type.sgml index 641c13e..d7d1a0b 100644 --- a/doc/src/sgml/ref/create_type.sgml +++ b/doc/src/sgml/ref/create_type.sgml @@ -433,7 +433,7 @@ CREATE TYPE

Re: [PATCHES] Doc patch: type modifiers

and output functions are exact inverses, which they are not. How about ... converts an array of modifier(s) for ...? Sounds good to me. Regards, Jeff Davis -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable

think it's worth considering enabling sync scans for non-clustered tables if it would not interfere with the release. Of course, a painless 8.3 release is the top priority. Regards, Jeff Davis ---(end of broadcast)--- TIP 6: explain analyze

Re: [PATCHES] Synchronized scans

On Sat, 2007-06-09 at 09:58 -0400, Tom Lane wrote: Jeff Davis [EMAIL PROTECTED] writes: * For a large table, do lazy_scan_heap, scan_heap, and a sequential scan usually progress at approximately the same rate? scan_heap would probably be faster than a regular seqscan, since it isn't

Re: [PATCHES] Synchronized scans

a problem. Regards, Jeff Davis ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PATCHES] Synchronized scans

, which is a bit odd, but a I'm confused about this part of the comment. Regards, Jeff Davis ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so

Re: [PATCHES] Synchronized scans

On Fri, 2007-06-08 at 11:57 -0700, Jeff Davis wrote: On Fri, 2007-06-08 at 14:36 -0400, Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Here's an update of the patch. I reverted the behavior at end of scan back to the way it was in Jeff's original patch, and disabled

Re: [PATCHES] Synchronized scans

backwards, we taint the scan such that it never reports. Regards, Jeff Davis ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [PATCHES] Synchronized scans

starting from the same place, and fetching the same tuples. Large LIMIT queries (larger than the number of pages between updates) do change the location in the hint, and so that's really the case you're worried about. Regards, Jeff Davis ---(end of broadcast

Re: [PATCHES] Synchronized scans

: SELECT * FROM bigtable; SELECT * FROM bigtable; with no concurrency at all, the returned order will be the same. In your patch, each full table scan leaves the hint at 16 pages before the position it started in, leading to different orders on the full table scans. Regards, Jeff Davis

Re: [PATCHES] Synchronized scans

pointed out. If we wanted to reduce the occurrence of this phenomena, we could perhaps time out the hints so that it's impossible to pick up a hint from a scan that finished 5 minutes ago. It doesn't seem helpful to further obscure the non-determinism of the results, however. Regards, Jeff

Re: [PATCHES] Synchronized scans

, here. But it's fair to say that a scan should clear any state when it's done. Regards, Jeff Davis ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about

Re: [PATCHES] Synchronized scans

is a concurrent scan, you'd still see different ordering. Removing the entry when a scan is over would just make it harder to trigger. Agreed. I don't know for sure whether that's good or bad, but it would make the nondeterminism less immediately visible. Regards, Jeff Davis

Re: [PATCHES] Synchronized scans

have happened. At this point, you're talking about rewinding the scan (how far?), which I originally coded for with sync_seqscan_offset. That feature didn't prove very useful (yet), so I removed it. Regards, Jeff Davis ---(end of broadcast

Re: [PATCHES] Synchronized Scan WIP patch

in cache would be useful to test if the lock contention is a problem. Regards, Jeff Davis ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PATCHES] Seq scans status update

On Tue, 2007-05-29 at 17:43 -0700, Jeff Davis wrote: Hmm. But we probably don't want the same buffer in two different backends' rings, either. You *sure* the sync-scan patch has no interaction with this one? I will run some tests again tonight, I think the interaction needs more

Re: [PATCHES] Seq scans status update

relation will overlap completely, right? We might not be at the ideal, but the sets of buffers in the rings shouldn't be disjoint, should they? Regards, Jeff Davis ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send

Re: [PATCHES] Synchronized Scan

On Mon, 2007-05-21 at 16:03 +0200, Peter Eisentraut wrote: Am Montag, 21. Mai 2007 00:01 schrieb Jeff Davis: Here is the latest version of my patch that's revised according to my discussions with Heikki and Simon: This patch was apparently done against 8.2.4, but it doesn't apply to CVS

Re: [PATCHES] Synchronized Scan WIP patch

remove sync_seqscan_threshold=real and instead use a simple enable/disable boolean that sets the threshold at a constant fraction of NBuffers (most likely the same fraction as Simon's recycle buffers patch) Regards, Jeff Davis diff -cr postgresql-8.2.3/src/backend/access/heap/heapam.c

Re: [PATCHES] Synchronized Scan WIP patch

On Thu, 2007-03-15 at 08:27 +, Simon Riggs wrote: On Wed, 2007-03-14 at 01:42 -0700, Jeff Davis wrote: SYNC_SCAN_REPORT_INTERVAL 100 Jeff, This will stop SeqScans from working with buffer recycling, unless we put the recycle limit to more than 100. That was why I requested you set

[PATCHES] Synchronized Scan WIP patch

should activate at the same threshold as Simon's scan_recycle_buffers feature. Should we make a #define BIG_SCAN_THRESHOLD NBuffers/2 to use for both sync_seqscan and for scan_recycle_buffers? Regards, Jeff Davis diff -cr postgresql-8.2.3/src/backend/access/heap/heapam.c postgresql-8.2.3

Re: [PATCHES] scan_recycle_buffers

. As Tom pointed out, the value is already in memory by the time it gets to my code. My code just reads that value from memory. Regards, Jeff Davis ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [PATCHES] scan_recycle_buffers

my results. I would expect that the CPU usage will increase, but it might not make a big difference in the overall cache hit rate if you count OS buffer cache hits. Regards, Jeff Davis ---(end of broadcast)--- TIP 4: Have you searched our

Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)

, Jeff Davis ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

[PATCHES] fix xact.c for bad pointer checking

the orginal author intended for an invalid savepoint name anyway. Regards, Jeff Davis --- src/backend/access/transam/xact.c.old 2004-08-03 03:18:12.0 -0700 +++ src/backend/access/transam/xact.c 2004-08-03 03:19:05.0 -0700 @@ -2529,7 +2529,7 @@ target = target