On Mon, Feb 08, 2010 at 08:20:04PM -0500, Tom Lane wrote:
MSVC builds are broken from a missing _isnan function on the ECPG tests.
Do we need to link in a math lib or something there?
It looks to me like the problem is that that test is being compiled
without benefit of any
On Tue, Feb 9, 2010 at 9:39 AM, Michael Meskes mes...@postgresql.org wrote:
Actually I was hoping someone with some Windows experience would take a look
at
it or Zoltan would come up with a fix, after all it was his addition. :-)
Looking at the portability header file it appears that
On Tuesday, February 9, 2010, Dave Page dp...@pgadmin.org wrote:
On Tue, Feb 9, 2010 at 9:39 AM, Michael Meskes mes...@postgresql.org wrote:
Actually I was hoping someone with some Windows experience would take a look
at
it or Zoltan would come up with a fix, after all it was his addition.
Michael Meskes írta:
On Mon, Feb 08, 2010 at 08:20:04PM -0500, Tom Lane wrote:
MSVC builds are broken from a missing _isnan function on the ECPG tests.
Do we need to link in a math lib or something there?
It looks to me like the problem is that that test is being compiled
without
Not even a comment? As I said, performance results on my system
were very good
I know you're all very busy getting 9.0 out, but I think the results in
heap scanning + sort instead of index scanning for CLUSTER are
very good... I would like to know if I did something wrong/I should
improve
KaiGai Kohei kai...@ak.jp.nec.com wrote:
I don't think this is necessarily a good idea. We might decide to treat
both things separately in the future and it having them represented
separately in the dump would prove useful.
I agree. From design perspective, the single section approach
I've been discussing this with Josh, Heikki, and Peter E. over the past
few weeks.
As Peter observed years ago, prepared statements can perform badly
because their plans are overly generic. Also, statistics change and
sometimes plans should change with them. It would be nice if we could
(2010/02/09 20:16), Takahiro Itagaki wrote:
KaiGai Koheikai...@ak.jp.nec.com wrote:
I don't think this is necessarily a good idea. We might decide to treat
both things separately in the future and it having them represented
separately in the dump would prove useful.
I agree. From design
For the regression test, I am inclined to just do
#ifdef WIN32
#define isnan(x) _isnan(x)
#define isinf(x) _isinf(x)
#endif
Well the isinf() macro is different in win32.h. I did make a change and
apparently red_bat is now green again. Hopefully that was it.
Michael
--
Michael Meskes
On Tue, Feb 9, 2010 at 02:20, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a
recent RADIUS support fix. Looks like we might need to include win32.h
in there.
That was discussed already. I
(please Cc me on replies, I am not subscribed)
Hi,
libpq currently does not use TCP keepalives. This is a problem in our
case where we have some clients waiting for notifies and then the
connection is dropped on the server side. The client never gets the FIN
and thinks the connection is up.
On Tue, Feb 9, 2010 at 14:03, Tollef Fog Heen
tollef.fog.h...@collabora.co.uk wrote:
(please Cc me on replies, I am not subscribed)
Hi,
libpq currently does not use TCP keepalives. This is a problem in our
case where we have some clients waiting for notifies and then the
connection is
Yeb Havinga wrote:
I've been discussing this with Josh, Heikki, and Peter E. over the
past few weeks.
Is this searchable in the archives? I'm interested in ideas discussed.
No, sorry. These were face-to-face discussions at linux.conf.au and FOSDEM.
If a prepared statement takes
On 09/02/10 12:08, Jeroen Vermeulen wrote:
= Projected-cost threshold =
[snip - this is the simple bit. Sounds very sensible. ]
= Actual-cost threshold =
Also stop using the generic plan if the statement takes a long time to
run in practice.
Do you mean:
1. Rollback the current query and
Jeroen Vermeulen wrote:
I've been discussing this with Josh, Heikki, and Peter E. over the
past few weeks.
Is this searchable in the archives? I'm interested in ideas discussed.
If a prepared statement takes parameters, and the generic plan has a
high projected cost, re-plan each EXECUTE
Robert Haas escribió:
On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
How do we now that it works?
Visual inspection? It's not very complicated.
Well, that works if you assume the trivial/usual malloc/free coding
style, but it fails in the hypothetical
First of all let me say that from such incredible hackers as the
PostgreSQL people I'd have expected the ability to find my email address
and maybe keep me or (even better) the psycopg mailing list in CC. That
would have avoided a lot of confusion both on the license and the status
of psycopg2. If
On Tuesday 09 February 2010 13:08:54 Jeroen Vermeulen wrote:
I've been discussing this with Josh, Heikki, and Peter E. over the past
few weeks.
As Peter observed years ago, prepared statements can perform badly
because their plans are overly generic. Also, statistics change and
sometimes
]] Magnus Hagander
| Seems reasonable to add this. Are there any scenarios where this can
| cause trouble, that would be fixed by having the ability to select
| non-standard behavior?
Well, it might be unwanted if you're on a pay-per-bit connection such as
3G, but in this case, it just makes
Good idea, implemented.
Hmm. I think your implementation is prone to overflow in two places -
both when computing step, and also when stepping through the array.
Pls, point me, I don't see that
! step |= (step 1);
! step |= (step 2);
! step |= (step 4);
! step
On Tue, Feb 9, 2010 at 1:56 PM, Federico Di Gregorio f...@initd.org wrote:
Btw, I was
at FOSDEM as probably other PostgreSQL people were and all this could
have been discussed while drinking a couple of beers if only someone
cared to contact me.
Hmm, I resent that. As one of the people at
Richard Huxton wrote:
= Actual-cost threshold =
Also stop using the generic plan if the statement takes a long time to
run in practice.
Do you mean:
1. Rollback the current query and start again
2. Mark the plan as a bad one and plan again next execute
If you can figure out how to do #1
On 09/02/2010 15:22, Dave Page wrote:
On Tue, Feb 9, 2010 at 1:56 PM, Federico Di Gregorio f...@initd.org wrote:
Btw, I was
at FOSDEM as probably other PostgreSQL people were and all this could
have been discussed while drinking a couple of beers if only someone
cared to contact me.
Hmm, I
Andres Freund wrote:
= Actual-cost threshold =
Also stop using the generic plan if the statement takes a long time to
run in practice. Statistics may have gone bad. It could also be a
one-off due to a load peak or something, but that's handled by:
That is not that easy. It means that you
Tollef Fog Heen wrote:
(please Cc me on replies, I am not subscribed)
Hi,
libpq currently does not use TCP keepalives. This is a problem in our
case where we have some clients waiting for notifies and then the
connection is dropped on the server side. The client never gets the FIN
and thinks
On Tue, Feb 9, 2010 at 15:28, Federico Di Gregorio f...@initd.org wrote:
On 09/02/2010 15:22, Dave Page wrote:
On Tue, Feb 9, 2010 at 1:56 PM, Federico Di Gregorio f...@initd.org wrote:
Btw, I was
at FOSDEM as probably other PostgreSQL people were and all this could
have been discussed while
On 09/02/10 14:25, Jeroen Vermeulen wrote:
Richard Huxton wrote:
= Actual-cost threshold =
Also stop using the generic plan if the statement takes a long time to
run in practice.
Do you mean:
1. Rollback the current query and start again
2. Mark the plan as a bad one and plan again next
On 02/09/2010 08:46 AM, Jeroen Vermeulen wrote:
This sounds like a really nice to have feature. Maybe it'd also be
possible to skip replanning between executes if the current bound
values are 'indexwise-equivalent' to the values used at previous
planning, i.e. nothing in the statistics
On Tue, Feb 9, 2010 at 13:52, Magnus Hagander mag...@hagander.net wrote:
On Tue, Feb 9, 2010 at 02:20, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a
recent RADIUS support fix. Looks like we
[Resending; I accidentally failed to copy the list.]
Federico Di Gregorio f...@initd.org wrote:
the logical choice is plain LGPL3. I am open to motivated
suggestions about other licenses but I'll ignore such crap as BSD
is more open than LGPL.
Well, I don't know about more open, but I find
On Mon, Feb 8, 2010 at 6:07 PM, David E. Wheeler da...@kineticode.com wrote:
On Feb 8, 2010, at 5:15 AM, Magnus Hagander wrote:
The text is about 180Kb. PostgreSQL takes ~40 seconds without the
patch, ~36 seconds with it, to extract the match from it. Perl takes
0.016 seconds.
Obviously we
Hello,
I am returning back to message
http://archives.postgresql.org/pgsql-general/2010-02/msg00119.php
Our implementation of variadic parameters missing correct handling
test on NULL, and test on non constant value.
This patch add correct tests for variadic parameters. Probably
Gen_fmgrtab.pl
Magnus Hagander mag...@hagander.net writes:
Here's a patch that fixes this. I put it locally for the radius
authentication for now, since we don't use this anywhere else. Should
we put this in /port/ somewhere, or is this good for now?
How about dropping it in
Pavel Stehule pavel.steh...@gmail.com writes:
+ /*
+ * If function has variadic argument, skip calling
+ * when variadic array contains NULL values.
+ */
I don't think this is right at all. The strict check ought to apply to
the array
On Tue, Feb 9, 2010 at 17:11, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Here's a patch that fixes this. I put it locally for the radius
authentication for now, since we don't use this anywhere else. Should
we put this in /port/ somewhere, or is this good
On Tue, Feb 9, 2010 at 5:49 AM, Leonardo F m_li...@yahoo.it wrote:
Not even a comment? As I said, performance results on my system
were very good
Hi Leonardo,
Perhaps you could supply a .sql file containing a testcase illustrating the
performance benefits you tested with your patch -- as
On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen j...@xs4all.nl wrote:
= Projected-cost threshold =
If a prepared statement takes parameters, and the generic plan has a high
projected cost, re-plan each EXECUTE individually with all its parameter
values bound. It may or may not help, but
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
+ /*
+ * If function has variadic argument, skip calling
+ * when variadic array contains NULL values.
+ */
I don't think this is right at all. The strict
Thom Brown wrote:
On 9 February 2010 01:57, Fujii Masao masao.fu...@gmail.com wrote:
The attached patch changes the layout according to your suggestion
(but with a small modification). Here is the new layout:
---
Chapter 24. Backup and Restore
24.1. SQL Dump
On Mon, 8 Feb 2010, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It seems a bit strange to have all the rb_free_recursive support and not
use it anywhere ... and a freefunc callback even, whose only
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen j...@xs4all.nl wrote:
Periodically re-plan prepared statements on EXECUTE. This is also a chance
for queries that were being re-planned every time to go back to a generic
plan.
The most common problem
kevina...@hotmail.com (Kevin Ar18) writes:
Of course all of this is from the perspective of Python users. Of
course, you have your own features that you want from your end (from
PostgreSQL's perspective). Perhaps this info would help you to know
which avenue to pursue.
No, those seem like
Pavel Stehule pavel.steh...@gmail.com writes:
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
I don't think this is right at all.
yes, this isn't clear. My arguments for change:
a) the behave depends on types - any is different than others.
So what? variadic any is different in a lot of ways.
b)
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
I don't think this is right at all.
yes, this isn't clear. My arguments for change:
a) the behave depends on types - any is different than others.
So what? variadic
Pavel Stehule pavel.steh...@gmail.com writes:
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
So what? Â variadic any is different in a lot of ways.
implementation is different, but from users perspective there can not
be differences. I am not sure. From my programmer's view is all ok.
But I believe
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
So what? variadic any is different in a lot of ways.
implementation is different, but from users perspective there can not
be differences. I am not sure. From my
I was rather surprised to find this code still present:
/*
* We set up the lockRelId in case anything tries to lock the dummy
* relation. Note that this is fairly bogus since relNode may be
* different from the relation's OID. It shouldn't really matter
Seems inconsistent ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Seems inconsistent ...
Indeed. Seems like an oversight.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
Seems inconsistent ...
Indeed. Seems like an oversight.
OK, will fix since I'm fooling with that code anyway.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
Seems inconsistent ...
Indeed. Seems like an oversight.
OK, will fix since I'm fooling with that code anyway.
Thanks. While we're at it, the comment above visibilitymap_truncate()
has a
I was recently experimenting with explain analyze and I realized there
are two things arguably wrong with the Buffers output in explain
analyze:
Firstly, it's printing out a number of buffers. We spent a lot of
effort making all GUC variables use units of memory like kB and MB
so the user should
Tom Lane wrote:
I was rather surprised to find this code still present:
/*
* We set up the lockRelId in case anything tries to lock the dummy
* relation. Note that this is fairly bogus since relNode may be
* different from the relation's OID. It shouldn't really
On 2010-02-08 18:42 +0200, Robert Haas wrote:
On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Here's an updated patch. Only changes from the previous patch are
fixing the above issue and a regression test for it.
- I'm not sure that canSetTag is the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I started looking at the callers of CreateFakeRelcacheEntry to see if
any of them actually take a lock on the Relation. It seems not, so maybe
we should just set those to InvalidOid, and add an
Assert(OidIsValid(dbId)
On 2/9/10 11:50 AM, Greg Stark wrote:
Secondly, I think it's printing the total buffer usage for that node
across the whole query -- not the average per iteration. I agree that
the average is probably more confusing but it's what we do for every
other stat. Do we want to be consistent? Call
Magnus Hagander wrote:
IIRC, we've had zero reports on whether the patch worked at all on 8.2
in an environment where the problem actually existed. So yes, some
testing and feedback would be much apprecaited.
//Magnus
Thanks for your quick reply.
We upgraded to Service Pack 2 and it solved
On Mon, 2010-02-08 at 22:13 -0800, Jeff Davis wrote:
I would like to support encoded text, but I think there are other
problems. For instance, what if one server has a client_encoding that
doesn't support some of the glyphs being sent by the notifying backend?
Then we have a mess, because we
Jeff Davis pg...@j-davis.com writes:
Looking at the documentation, it appears that all of the server
encodings represent 7-bit ascii characters using the same 7-bit ascii
representation. Is that true?
Correct. We only support ASCII-superset encodings, both for frontend
and backend.
Limiting
On Tue, Feb 9, 2010 at 3:26 PM, Josh Berkus j...@agliodbs.com wrote:
On 2/9/10 11:50 AM, Greg Stark wrote:
Secondly, I think it's printing the total buffer usage for that node
across the whole query -- not the average per iteration. I agree that
the average is probably more confusing but it's
Greg Stark st...@mit.edu writes:
I already have a patch to do this but it's a bit grotty -- do we want
to have a generic format string in snprintf in case we need it
somewhere else other than explain.c?
No. Custom format specifiers that take arguments will confuse the heck
out of gcc's
Boszormenyi Zoltan írta:
Korry Douglas írta:
I have the $SUBJECT problem loading my own
module in PostgreSQL. The server is HP-UX/ia64,
PostgeSQL 8.4.2 was compiled with HP CC.
pl/PgSQL can be loaded fine.
...:/usr/local/pgsql/pgsql-cc-8.4/lib# ldd odbclink.so
libodbc.so.1 =
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 9, 2010 at 3:26 PM, Josh Berkus j...@agliodbs.com wrote:
I'd prefer to have the average; it's very confusing to have an explain
row which has the cost per iteration, but the buffer usage per node.
The cost per iteration thing is IMO one of
Jeroen Vermeulen j...@xs4all.nl writes:
I think we should be careful not to over-think this. Planning isn't *that*
costly, so apply Amdahl's Law liberally. I'm proposing some easy things we
could do without adding much overhead or maintenance burden; I've been
assuming that getting intimate
On Tue, Feb 9, 2010 at 5:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 9, 2010 at 3:26 PM, Josh Berkus j...@agliodbs.com wrote:
I'd prefer to have the average; it's very confusing to have an explain
row which has the cost per iteration, but the
On Tue, Feb 9, 2010 at 4:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Davis pg...@j-davis.com writes:
Looking at the documentation, it appears that all of the server
encodings represent 7-bit ascii characters using the same 7-bit ascii
representation. Is that true?
Correct. We only
Federico Di Gregorio wrote:
First of all let me say that from such incredible hackers as the
PostgreSQL people I'd have expected the ability to find my email address
and maybe keep me or (even better) the psycopg mailing list in CC. That
would have avoided a lot of confusion both on the license
On Tue, Feb 9, 2010 at 3:13 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-08 18:42 +0200, Robert Haas wrote:
On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Here's an updated patch. Only changes from the previous patch are
fixing the
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 9, 2010 at 5:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if you want to put forward a proposal to get rid of that approach
entirely, go ahead. But it doesn't seem like a good idea to me for
EXPLAIN to print some numbers according to
On Tue, Feb 9, 2010 at 5:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 9, 2010 at 5:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if you want to put forward a proposal to get rid of that approach
entirely, go ahead. But it doesn't seem like
On 2010-02-08 21:30 +0200, I wrote:
This doesn't exactly work anymore since we modify the snapshot after
calling ExecInitScan(). I'm not really familiar with this part of the
code, so I'm asking: is there a simple enough way around this? Would
updating scan-rs_nblocks before scanning the
On Tue, 2010-02-09 at 16:51 -0500, Tom Lane wrote:
Limiting NOTIFY payloads to 7-bit would definitely avoid the issue.
The question is if that's more of a pain than a benefit.
I don't see any alternative. If one backend sends a NOTIFY payload that
contains a non-ASCII character, there's a risk
I just realized that log_error_verbosity is in the wrong section in
postgresql.conf and in our manual. It is listed under When to log
when in fact it should be in the What to log section.
I also added documentation of what terse mode actually does. I added
verbosity information a few weeks ago.
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 9, 2010 at 5:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
A more important point is that it would be a nontrivial change, both as
to code and documentation, and it's too late for such in 9.0. So what
we ought to be confining the discussion to
On Tue, Feb 9, 2010 at 10:42 PM, Robert Haas robertmh...@gmail.com wrote:
A more important point is that it would be a nontrivial change, both as
to code and documentation, and it's too late for such in 9.0. So what
we ought to be confining the discussion to right now is what 9.0 should
print
Jeff Davis wrote:
On Tue, 2010-02-09 at 16:51 -0500, Tom Lane wrote:
Limiting NOTIFY payloads to 7-bit would definitely avoid the issue.
The question is if that's more of a pain than a benefit.
I don't see any alternative. If one backend sends a NOTIFY payload that
Wouldn't binary payloads
On Tue, Feb 9, 2010 at 6:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 9, 2010 at 5:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
A more important point is that it would be a nontrivial change, both as
to code and documentation, and it's too late
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-02-08 21:30 +0200, I wrote:
This doesn't exactly work anymore since we modify the snapshot after
calling ExecInitScan(). I'm not really familiar with this part of the
code, so I'm asking: is there a simple enough way around this?
On 2010-02-10 02:19 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Does this sound completely unacceptable?
You still haven't explained why it's a good idea to change the snapshot
after the executor has started. Right at the moment I'm prepared to
reject the
On Tue, 2010-02-09 at 19:02 -0500, Andrew Chernow wrote:
Wouldn't binary payloads be an alternative? NOTE: I may have missed this
discussion. Sorry if it has already been covered.
The Notify struct has a char * field, which can't hold embedded NULL
bytes, so it can't really be binary. But it
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 9, 2010 at 6:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not in the least. Fixing EXPLAIN to consistently print totals would
involve changes in (at least) the treatment of estimated costs, and very
possibly some changes in the
(2010/02/09 21:18), KaiGai Kohei wrote:
(2010/02/09 20:16), Takahiro Itagaki wrote:
KaiGai Koheikai...@ak.jp.nec.com wrote:
I don't think this is necessarily a good idea. We might decide to treat
both things separately in the future and it having them represented
separately in the dump
On Tue, 9 Feb 2010, Mark Mielke wrote:
In a current commercial app we have that uses JDBC and prepared plans for
just about everything, it regularly ends up with execution times of 30+
milliseconds when a complete plan + execute would take less than 1
millisecond.
PostgreSQL planning is
On Wed, Feb 10, 2010 at 12:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The reason that EXPLAIN prints things the way it does is so that actual
costs/times are comparable to estimated costs.
Oh, that was a thought I had along the way but forgot to mention in my
email: since the buffer usage isn't
Jeff Davis wrote:
Also, the query starts out as text, so we need a way to interpret the
text in an encoding-independent way.
So, I think ASCII is the natural choice here.
It's not worth hanging up this facility over this issue, ISTM. If we
want something more that ASCII then a base64
On Tue, Feb 9, 2010 at 11:34 PM, Andrew Chernow a...@esilo.com wrote:
If you really want libpq to manage this, I think you need to expose the
probe interval and timeouts.
Agreed.
Previously I was making the patch that exposes them as conninfo
options so that the standby can detect a network
Greg Stark st...@mit.edu writes:
On Wed, Feb 10, 2010 at 12:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The reason that EXPLAIN prints things the way it does is so that actual
costs/times are comparable to estimated costs.
Oh, that was a thought I had along the way but forgot to mention in my
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-02-10 02:19 +0200, Tom Lane wrote:
You still haven't explained why it's a good idea to change the snapshot
after the executor has started. Right at the moment I'm prepared to
reject the patch on that ground alone.
The patch only
Andrew Dunstan and...@dunslane.net writes:
Jeff Davis wrote:
So, I think ASCII is the natural choice here.
It's not worth hanging up this facility over this issue, ISTM. If we
want something more that ASCII then a base64 or hex encoded string could
possibly meet the need in the first
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Jeff Davis wrote:
So, I think ASCII is the natural choice here.
It's not worth hanging up this facility over this issue, ISTM. If we
want something more that ASCII then a base64 or hex encoded string could
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Jeff Davis wrote:
So, I think ASCII is the natural choice here.
It's not worth hanging up this facility over this issue, ISTM.
If we want something more that ASCII then a base64 or hex
encoded string
Alvaro Herrera alvhe...@commandprompt.com writes:
Andrew Dunstan wrote:
True. It's a workaround, but I think it's acceptable at this stage.
We need to get some experience with this facility before we can
refine it.
Hmm? If we decide now that it's not going to have encoding conversion,
we
Bruce Momjian br...@momjian.us wrote:
Where are we on this patch? We should at least implement the completion
for 'LANGUAGE' in 'DO', and use the existing pg_language query for
completion. I am attaching a patch that does exactly this.
I don't think we need the patch except adding DO to
We've added some new syntax in HEAD, but psql tab-completion is out of sync.
Here is a patch to support the following syntax in tab-completion:
- top-level DO
- ALTER TABLE/INDEX/TABLESPACE SET/RESET with options
- ALTER TABLE ALTER COLUMN SET/RESET with options
- CREATE TRIGGER
KaiGai Kohei kai...@ak.jp.nec.com wrote:
The attached patch fixed up the cleanup query as follows:
+ appendPQExpBuffer(dquery,
+ SELECT pg_catalog.lo_unlink(oid)
+ FROM pg_catalog.pg_largeobject_metadata
+ WHERE oid = %s;\n,
Hi Andrew and all,
I am still struggling with the branch repositories. I tried to checkout from
branch repositories but got error no such repositories:
$ cvs -z3 -d
:pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/REL8_4_STABLE
co -P pgsql
/projects/REL8_4_STABLE: no such repository
We have an optimization to bulkload date in pg_restore, but the code
only works in parallel restore (--jobs = 2). Why don't we do the
same optimization in the serial restore (--jobs = 1) ?
We checks is_parallel to decide to use BEGIN-TRUNCATE-COPY:
if (is_parallel te-created)
but we can
Final, I tried:
$ cvs -z3 -d :pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/cvsroot
co -r REL8_3_STABLE -P pgsql
Checked file configure.in. Around line 20, there is line:
AC_INIT([PostgreSQL], [8.3.9], [pgsql-b...@postgresql.org])
Not sure that indicates version 8.3.9?
But still,
On Tue, Feb 9, 2010 at 8:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps instead of looking to change the actual times we should look
at a way to include total time spent in each node.
You can already get that by multiplying the displayed total time by the
number of loops. Robert does have
On Tue, Feb 9, 2010 at 10:35 PM, M Z jm80...@gmail.com wrote:
Final, I tried:
$ cvs -z3 -d
:pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/cvsroot co -r
REL8_3_STABLE -P pgsql
Checked file configure.in. Around line 20, there is line:
AC_INIT([PostgreSQL], [8.3.9],
1 - 100 of 113 matches
Mail list logo
