lock is set back or the data repeats.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
patch does this also, for similar reasons.
>
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
seq scans patch?
>
I will test it and post 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)
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
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.
cumentation (after we stabilize the GUC names and meanings)
* Possibly remove sync_seqscan_threshold= 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 D
nters will be useful.
Regards,
Jeff Davis
diff -rc postgresql-8.2.4/src/backend/access/heap/heapam.c postgresql-8.2.4-ss/src/backend/access/heap/heapam.c
*** postgresql-8.2.4/src/backend/access/heap/heapam.c 2007-02-04 12:00:49.0 -0800
--- postgresql-8.2.4-ss/src/backend/access/heap/he
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.
there are a large number
of scans on the same table and the I/O system is fast enough that it
causes lock contention on the buffers in the rings. Is this the case
you're worried about?
Also, keep in mind that I have added a SyncScanLock after I ran those
tests. That could have an effect.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
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 agai
t scans on the same 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/readin
their own rings.
>
Oh, I see what you mean. The rings will actually become sparsely
populated with many concurrent scans, and therefore, extend outside of
L2 cache.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 3: Have
also think the optimization of only reporting when the block is not
found 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
pful to further obscure the non-determinism of the
results, however.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze is your friend
but fewer would be effective to cache; and the table
in question is larger than the large table threshold. I'm just trying to
add some perspective about what we're fixing, here.
But it's fair to say that a scan should clear any state when it's done.
Regards,
Jeff Davis
--
;t know for sure whether that's good or bad, but it would
make the nondeterminism less immediately visible.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
nothing.
This would only matter when there weren't other scans. When concurrent
scans were happening, chances are the PID wouldn't match anyway, and
thus not be removed.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 3: Have you
se no reports will happen
(other than the starting location, which won't matter in this case).
If the data is more than that, then at least one report would have
happened. At this point, you're talking about rewinding the scan (how
far?), which I originally coded for with s
in the hint, so if you repeat them, the queries keep 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,
tch, if you do:
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,
le ss_report_location if the scan is moving
backwards.
I might go so far as to suggest if the scan *ever* moves 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
I'm not sure if that's even a problem.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
ion will restart the scan, 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 co
other? AFAIK the only case where
> it'd happen is if someone reads forwards in a large-seqscan cursor
> for awhile and then reads backwards. You could argue that doing
> that is a good reason to drop them out of the syncscan pack ...
>
I don't feel strongly a
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 wa
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
he same execution path 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
ave much less of a performance impact when run against an active
system.
I 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
-
e something like "textual" (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.s
t; sound like the input 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
rmation in the comments 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 c1a
certainty;
> (2) 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.
argument" -> "variadic
parameter must be the last parameter to the function"
Those are just suggested wordings.
Regards,
Jeff Davis
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
unctions
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
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 dec
s should be allowed.
I suggest the following error message rewording:
"variadic argument isn't an array" should be something like: "variadic
argument must be an array".
Regards,
Jeff Davis
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
akes more sense than requiring one
argument. It also seems a little more natural from a function author's
perspective.
Regards,
Jeff Davis
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
37 matches
Mail list logo
