On Mon, 2004-12-13 at 04:39, Mark Kirkwood wrote:
I am seeing a reasonably reproducible performance boost after applying
your patch (I'm not sure if that was one of the main objectives, but it
certainly is nice).
I *was* seeing a noticeable decrease between 7.4.6 and 8.0.0RC1 running
On Mon, 2004-12-13 at 02:43, Neil Conway wrote:
On Sun, 2004-12-12 at 22:08 +, Simon Riggs wrote:
On Sun, 2004-12-12 at 05:46, Neil Conway wrote:
Is the plan to make bgwriter_percent = 100 the default setting?
Hmm...must confess that my only plan is:
i) discover dynamic behaviour
Hi strk,
(cut)
Taking a look at join selectivity...
For a query like this:
SELECT id FROM table1, table2
WHERE table1.geom table2.geom;
RESTRICT selectivity is invoked twice and
JOIN selectivity is invoked once.
The RESTRICT code is not able to find a costant part
Tom,
Just for testing, I stuffed it into ExecEvalVar under the switch statement in
execQual.c. This was a chosen spot I was fairly certain I could get some kind
of output.
TupleTableSlot *slot;
TupleDesc tuple_type;
The above portion is actually part of the delivered source code.
Hi strk,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 13 December 2004 14:05
To: Mark Cave-Ayland
Cc: [EMAIL PROTECTED]
Subject: Re: [postgis-devel] RE: join selectivity
On Mon, Dec 13, 2004 at 12:16:15PM -, Mark Cave-Ayland wrote:
Hi strk,
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Instead of doing that, do:
--with-includes=/usr/include/et
This same workaround is in the RPMs. I wonder if it would be
worthwhile for configure to assume the above when --with-krb5 is
mentioned. I don't know how widespread this
Schoudel, Brian [EMAIL PROTECTED] writes:
Just for testing, I stuffed it into ExecEvalVar under the switch statement in
execQual.c. This was a chosen spot I was fairly certain I could get some
kind of output.
Oh. In that case you're probably going to be looking at a tupledesc
that was
I have a strange but reproducible problem where a query does not seem to
return the same results.
esp=# select 1::int4, * from data1.po_line_file
esp-# where pol_po_no = '0002' and
esp-# (pol_po_no = '0002' and pol_po_rel_no = 0) and
esp-# (pol_po_no = '0002'
Mark Cave-Ayland [EMAIL PROTECTED] writes:
For a query like this:
SELECT id FROM table1, table2
WHERE table1.geom table2.geom;
RESTRICT selectivity is invoked twice and
JOIN selectivity is invoked once.
Hm, are you testing in a context where both tables have indexes that are
relevant
That is bizarre. Does EXPLAIN show any difference?
---
Merlin Moncure wrote:
I have a strange but reproducible problem where a query does not seem to
return the same results.
esp=# select 1::int4, * from
--On Montag, Dezember 13, 2004 17:23:06 +0100 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Instead of doing that, do:
--with-includes=/usr/include/et
This same workaround is in the RPMs. I wonder if it would be
worthwhile for configure
On Sat, 11 Dec 2004 18:28:15 -0500, Tom Lane [EMAIL PROTECTED] wrote:
I have applied the attached patch to HEAD in order to fix the problems
discussed in this thread:
http://archives.postgresql.org/pgsql-hackers/2004-12/msg00187.php
regards, tom lane
Well, I was
Andrew Dunstan [EMAIL PROTECTED] writes:
We still seem to have occasional problems with dropdb while running
contrib installcheck. The symptoms look like this:
I see this regularly on some platforms, and seldom/never on others.
I've also seen it happen when scripting a tight loop around the
On Mon, Dec 13, 2004 at 12:16:05PM -0500, Tom Lane wrote:
Mark Cave-Ayland [EMAIL PROTECTED] writes:
For a query like this:
SELECT id FROM table1, table2
WHERE table1.geom table2.geom;
RESTRICT selectivity is invoked twice and
JOIN selectivity is invoked once.
Hm, are you
Am Samstag, 4. Dezember 2004 00:12 schrieb Marc G. Fournier:
look her over ... I forced a sync to the ftp.postgresql.org server, so its
available there ... will announce later this evening baring any 'its
broken' commends ;)
You are building the documentation with old stylesheets. Please use
In recent discussion[1] with Simon Riggs, there has been some talk of
making some changes to the bgwriter. To summarize the problem, the
bgwriter currently scans the entire T1+T2 buffer lists and returns a
list of all the currently dirty buffers. It then selects a subset of
that list (computed
Neil Conway wrote:
(2) Remove bgwriter_percent. I have yet to hear anyone argue that
there's an actual need for bgwriter_percent in tuning bgwriter behavior,
and one less GUC var is a good thing, all else being equal. This is
effectively the same as #1 with the default changed, only less
Neil Conway [EMAIL PROTECTED] writes:
...
(2) Remove bgwriter_percent. I have yet to hear anyone argue that
there's an actual need for bgwriter_percent in tuning bgwriter behavior,
...
Of the three offered solutions, I agree that that makes the most sense
(unless Jan steps up with a strong
That is bizarre. Does EXPLAIN show any difference?
Uh oh.
esp=# reindex table data1.parts_order_line_file;
whoops, never mind that. In fact, I re-indexed the wrong table.
Reindexing makes no difference. Here, explain analyze and running query
in psql return different results. Observe:
Tom Lane wrote:
However, due consideration should also be given to
(4) Do nothing until 8.1.
At this point in the release cycle I'm not sure we should be making
any significant changes for anything less than a crashing bug.
If that's not the policy, then I don't understand the dev cycle state
Am Dienstag, 14. Dezember 2004 16:51 schrieb Brad Nicholson:
AIX 5.1
I applied Bruce's patch, configured with --enable-thread-safety and
everything went smoothly.
Nonetheless, threading support on AIX being a new feature, I don't think this
should go into 8.0.0.
--
Peter Eisentraut
[original seems lost - sorry if it's a dup]
We still seem to have occasional problems with dropdb while running
contrib installcheck. The symptoms look like this:
== dropping database regression ==
dropdb: database removal failed: ERROR: database regression is
On Mon, 2004-12-13 at 19:29 -0500, Tom Lane wrote:
A more radical solution would be to tweak libpq's PQfinish() to be a
synchronous close, ie, wait for the backend to exit before returning.
I think we've speculated about doing that in the past, but never been
fully convinced that it's worth
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2004-12-13 at 19:29 -0500, Tom Lane wrote:
A more radical solution would be to tweak libpq's PQfinish() to be a
synchronous close,
I can see this being useful in some situations, but I think the current
behavior is preferable for most clients.
Tom Lane said:
.
At the moment I think a sleep in the contrib makefile is sufficient
(though note I intended to apply it only to installcheck not the other
actions ;-))
If you're going to make a separate rule for installcheck (which I agree is a
good idea), please also consider making it
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I guess we could put a small sleep before dropdb in pg_regress.sh to
I'd prefer to put it in contrib/Makefile's installcheck rule, so that
we don't pay the price in contexts where it's not needed.
tiny patch attached. For
26 matches
Mail list logo
