On 26.02.2011 07:55, Tom Lane wrote:
So we really need some refactoring here. I dislike adding another
fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
but there may not be a better way.
Could you keep the sequence unchanged for non-EXPLAIN callers with some
- Original message -
On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański wulc...@wulczer.org
wrote:
On 24/02/11 14:10, Peter Eisentraut wrote:
Hm, perhaps, I put it in the details, because it sounded like the place
to put information that is not that important, but still helpful. It's
- Original message -
On Wed, Feb 9, 2011 at 5:22 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-02-08 at 00:32 -0500, Steve Singer wrote:
The documentation could probably still use more word-smithing but
that can happen later. I'm marking this as ready for a committer.
- Original message -
On Tue, Feb 15, 2011 at 6:04 PM, Jan Urbański wulc...@wulczer.org
wrote:
On 15/02/11 20:39, Peter Eisentraut wrote:
On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
[a bug that we don't know how to fix]
From this discussion I gather that we have a
On 26 February 2011 18:06, Bruce Momjian br...@momjian.us wrote:
Any progress on this?
I ended up doing most of the work, but never got around to finishing
it off. Thanks for the reminder, though. I'll get that one ready and
drop it onto the next CF.
Cheers,
BJ
--
Sent via pgsql-hackers
On 25 Feb 2011, at 13:18, Robert Haas wrote:
People coming from Oracle are not favorably
impressed either by the amount of monitoring data PostgreSQL can
gather or by the number of knobs that are available to fix problems
when they occur. We don't need to have as many knobs as Oracle and
On 2011-02-26 4:41 AM +0200, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
One thing bothers me though: what was the reason for requiring a
RETURNING clause for data-modifying statements in WITH?
That test was in your patch, no? I moved the code to another place
but
On Sat, Feb 26, 2011 at 10:57, Brendan Jurd dire...@gmail.com wrote:
On 26 February 2011 18:06, Bruce Momjian br...@momjian.us wrote:
Any progress on this?
I ended up doing most of the work, but never got around to finishing
it off. Thanks for the reminder, though. I'll get that one ready
On Sat, Feb 26, 2011 at 5:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So we really need some refactoring here. I dislike adding another
fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
but there may not be a better way. The only way I see to fix this
without changing
On Fri, Feb 25, 2011 at 14:26, Alvaro Herrera alvhe...@commandprompt.comwrote:
Excerpts from Rod Taylor's message of vie feb 25 14:03:58 -0300 2011:
How practical would it be for analyze to keep a record of response times
for
given sections of a table as it randomly accesses them and
On 26 February 2011 05:55, Tom Lane t...@sss.pgh.pa.us wrote:
Further experimentation has reminded me of why I didn't want to put such
processing in ExecutorEnd :-(. There are some nasty interactions with
EXPLAIN:
1. EXPLAIN ANALYZE fails to include the execution cycles associated with
On Sat, Feb 26, 2011 at 4:33 AM, Grzegorz Jaskiewicz
g...@pointblue.com.pl wrote:
On 25 Feb 2011, at 13:18, Robert Haas wrote:
People coming from Oracle are not favorably
impressed either by the amount of monitoring data PostgreSQL can
gather or by the number of knobs that are available to
On Sat, Feb 26, 2011 at 1:57 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Actually, we *do* have some idea which tables are hot. ?Or at least, we
could. ? Currently, pg_stats for tables are timeless; they just
accumulate from the last reset, which has always been a problem
2011/2/26 Jan Urbański wulc...@wulczer.org:
- Original message -
On Tue, Feb 15, 2011 at 6:04 PM, Jan Urbański wulc...@wulczer.org
wrote:
On 15/02/11 20:39, Peter Eisentraut wrote:
On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
[a bug that we don't know how to fix]
2011/2/26 Jan Urbański wulc...@wulczer.org:
The docs are included in the latest patch, and it turned out that disabling
implicit subxacts inside explicit subxacts is not a good idea, so it's been
fixed in the last patch. There are no unresolved issues AFAICT.
OK. Peter, are you planning to
Committed the last version.
I updated the documentation which previously claimed that what you
implemented wasn't supported.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Feb 16, 2011 at 7:06 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 16, 2011 at 12:59 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao masao.fu...@gmail.com
On lör, 2011-02-26 at 09:49 -0500, Robert Haas wrote:
OK. Peter, are you planning to commit this?
Yes.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On lör, 2011-02-26 at 09:34 +0100, Jan Urbański wrote:
- Original message -
On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański wulc...@wulczer.org
wrote:
On 24/02/11 14:10, Peter Eisentraut wrote:
Hm, perhaps, I put it in the details, because it sounded like the place
to put
On Sun, Feb 20, 2011 at 21:37, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Hi,
Magnus Hagander mag...@hagander.net writes:
Better late than never (or?), here's the final cleanup of
pg_streamrecv for moving into the main distribution, per discussion
back in late dec or early jan. It also
in spawn_restore:
child = (HANDLE) _beginthreadex(NULL, 0, (void *) parallel_restore,
args,
0, NULL);
if (child == 0)
But from my reading of the docs, _beginthreadex() returns -1 on error, not 0.
Bug, or
Greg Stark gsst...@mit.edu writes:
On Sat, Feb 26, 2011 at 5:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So we really need some refactoring here. I dislike adding another
fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
but there may not be a better way. The only way I
On Sat, Feb 26, 2011 at 4:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right at the moment we dodge that issue by disallowing wCTEs in cursors.
If we did allow them, then I would say that the wCTEs have to be run to
completion when the cursor is closed.
Does that really dodge anything? Isn't it
On Sat, Feb 26, 2011 at 16:51, Magnus Hagander mag...@hagander.net wrote:
in spawn_restore:
child = (HANDLE) _beginthreadex(NULL, 0, (void *) parallel_restore,
args,
0, NULL);
if (child == 0)
But from
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 26.02.2011 07:55, Tom Lane wrote:
So we really need some refactoring here. I dislike adding another
fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
but there may not be a better way.
Could you keep the
bruce wrote:
Josh Berkus wrote:
Right now pg_options_to_table() is not documented. Should it be?
Yes, I think so.
Done, with the attached, applied patch.
Oh, here is an example usage:
test= select pg_options_to_table(reloptions) from pg_class;
Still, having more data a user can probe would be nice.
I wonder why everyone avoids Microsoft's approach to the subject.
Apparently, they go in the 'auto-tune as much as possible' direction.
And tests we did a while ago, involving asking team from Microsoft and a
team from oracle to
On Tue, Feb 15, 2011 at 6:04 PM, Jan Urbański wulc...@wulczer.org
wrote:
On 15/02/11 20:39, Peter Eisentraut wrote:
On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
[a bug that we don't know how to fix]
From this discussion I gather that we have a problem here that
Hi,
I am writing some spatio-temporal function in postgis.
Like, ST_Enters( obj_geom, boundary_geom, time t1,time t2)
For example- Does vehicle enters in ABC between time t1 to t2?
Let us suppose, i take only one object geometry at a time and do compare
then i could not produce the output because
2011/2/26 PostgreSQL - Hans-Jürgen Schönig postg...@cybertec.at:
what we are trying to do is to explicitly store column correlations. so, a
histogram for (a, b) correlation and so on.
The problem is that we haven't figured out how to usefully store a
histogram for a,b. Consider the oft-quoted
On Sat, Feb 26, 2011 at 06:44:52PM +, Greg Stark wrote:
2011/2/26 PostgreSQL - Hans-Jürgen Schönig postg...@cybertec.at:
what we are trying to do is to explicitly store column correlations. so, a
histogram for (a, b) correlation and so on.
The problem is that we haven't figured out
On 2011-02-26 18:19, Magnus Hagander wrote:
Attached is an updated version of the patch that includes these
changes, as well as Windows support and an initial cut at a ref page
for pg_receivexlog (needs some more detail still).
I'm testing a bit more (with the previous version, sorry) and got
On Sat, Feb 26, 2011 at 20:48, Yeb Havinga yebhavi...@gmail.com wrote:
On 2011-02-26 18:19, Magnus Hagander wrote:
Attached is an updated version of the patch that includes these
changes, as well as Windows support and an initial cut at a ref page
for pg_receivexlog (needs some more detail
On 26 Feb 2011, at 14:45, Robert Haas wrote:
On Sat, Feb 26, 2011 at 4:33 AM, Grzegorz Jaskiewicz
I don't think *anyone* is avoiding that approach. There is almost
universal consensus here that auto-tuning is better than manual
tuning, even to the extent of being unwilling to add knobs
That would be nice; I'm basically abusing syncrep to this purpose. At
the same time, someone may need to be notified of such a switchover
occurring, and in event of failure, it'd be nice to bounce back to the
primary. Tangentially relevent, Virtual IP is not always an option,
such as on
Grzegorz Jaskiewicz wrote:
I guess that the systems could behave much better, but no one is
going to tweak settings for 50 different installations over 50
different type of data and 50 different sets of hardware.
If there was even a tiny amount of automation provided in the
postgresql, I
Hi hackers,
I am interested in extending Postgres with a generalized edit function like
SAS's compged[1], which is basically levenshtein distance with transposes (ab
- ba) and LOTS of different weights for certain ops (like insert a blank
versus delete from the end versus insert a regular
Greg Stark wrote:
Consider the oft-quoted example of a -- or
for Americans.
I'm not sure everyone realizes just how complicated this particular
issue is. If we can do a good job with U.S. city, state, zip code we
will have something which will handle a lot of cases.
Consider:
(1)
On 07.12.2010 05:51, Fujii Masao wrote:
On Tue, Dec 7, 2010 at 12:22 PM, Robert Haasrobertmh...@gmail.com wrote:
Fair enough. How about increasing the default to 10 seconds?
Since bgwriter has already using 10s as a nap time if there is no
configured activity, I think that 10s is non-nonsense
Fork,
1. Does anybody else care? I would love to see this in contrib, but if the
chances are slim, then I would like to know that too.
That really depends on how well it works, and how much code it is. It's
way too early for anyone to have a viewpoint on this. For example, a
few years ago
On Sat, Feb 26, 2011 at 4:19 PM, Josh Berkus j...@agliodbs.com wrote:
Anyway, if it's ASCII-only, that's a guaranteed way to make sure it
isn't taken seriously.
Pre-9.1 levenshtein is ASCII-only, and I think some of the other stuff
in contrib/fuzzystrmatch still is. We had to work pretty hard
On 2011-02-26 7:18 PM, Tom Lane wrote:
IMO the major disadvantage of a refactoring like this is the possibility
of sins of omission in third-party code, in particular somebody not
noticing the added requirement to call ExecutorFinish. We could help
them out by adding an Assert in ExecutorEnd to
On Sat, Feb 26, 2011 at 12:52:40AM -0500, Robert Haas wrote:
On Sat, Feb 26, 2011 at 12:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yay! I'm excited about this, particularly the possible pipelining
stuff, where you can do WITH (DELETE .. RETURNING
Hello,
I've been playing with 'native XML' for a while and now wondering if
further development of such a feature makes sense for Postgres.
(By not having brought this up earlier I'm taking the chance that the
effort will be wasted, but that's not something you should worry about.)
The code is
Hi all,
I noticed an off by one error in psql's verbose-mode display for \dg
and \du. In verbose mode, \dg and \du will not display the
Replication attribute:
test=# \dg rep
List of roles
Role name | Attributes | Member of
---+-+---
rep |
Robert Haas robertmhaas at gmail.com writes:
On Sat, Feb 26, 2011 at 4:19 PM, Josh Berkus josh at agliodbs.com wrote:
Anyway, if it's ASCII-only, that's a guaranteed way to make sure it
isn't taken seriously.
Pre-9.1 levenshtein is ASCII-only, and I think some of the other stuff
in
On 2/26/11 3:40 PM, Anton wrote:
I've been playing with 'native XML' for a while and now wondering if
further development of such a feature makes sense for Postgres.
(By not having brought this up earlier I'm taking the chance that the
effort will be wasted, but that's not something you should
On Fri, Feb 18, 2011 at 12:10 PM, Robert Haas robertmh...@gmail.com wrote:
IMHO, that's so broken as to be useless.
I would really like to have a solution to this problem, though.
Relying on TCP keepalives is weak.
Agreed.
I updated the replication timeout patch which I submitted before.
On Sat, Feb 26, 2011 at 7:40 PM, fork forkandw...@gmail.com wrote:
Pre-9.1 levenshtein is ASCII-only, and I think some of the other stuff
in contrib/fuzzystrmatch still is.
I am only looking at 9.0.3 for levenshtein, so I don't have any thoughts yet
on
multi-byteness so far. I will have
On Fri, Feb 25, 2011 at 8:40 AM, Greg Smith g...@2ndquadrant.com wrote:
I didn't get the Streaming Rep + Hot Standby features I wanted in 9.0 either.
But committing what was reasonable to include in that version let me march
forward with very useful new code, doing another year of
50 matches
Mail list logo
