2010/7/14 Pavel Stehule pavel.steh...@gmail.com:
this patch is significantly reduced original patch. It doesn't propose
a simple allocator - just eliminate a high memory usage for ispell
dictionary.
I don't think introducing new methods is a good idea. If you want a
simple allocator,
*i wrote to
pgsql-b...@postgresql.org
they tell me write to
pgsql-performa...@postgresql.org
they tell me write here*
*I don`t whant know how optimize query myself (i know it), and i think
it must do planner.*
I have a query:
SELECT d1.ID, d2.ID
FROM DocPrimary d1
JOIN DocPrimary d2
On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote:
Since it has been over a month since this review was posted and no new
version of the patch has appeared, I think we should mark this patch
as Returned with Feedback.
Mark posted a new patch 6 days ago, AFAICS.
Not sure I see any benefit
2010/7/13 Alexander Korotkov aekorot...@gmail.com:
Anyway I think that overhead is not ignorable. That's why I have splited
levenshtein_internal into levenshtein_internal and levenshtein_internal_mb,
and levenshtein_less_equal_internal into levenshtein_less_equal_internal and
2010/7/16 Jeff Davis pg...@j-davis.com:
I'd like to ask you to write additional documentation about btree_gist [1]
that the module will be more useful when it is used with exclusion
constraints together. Without documentation, no users find the usages.
| Example using an Exclusion Constraint
Hello
I am working on to_array, to_string functions and I am looking on
string_to_array function. I am surprised so this function is marked as
immutable
postgres=# select array_to_string(array[current_date],',');
array_to_string
-
2010-07-20
(1 row)
postgres=# set datestyle to
2010/7/20 Itagaki Takahiro itagaki.takah...@gmail.com:
2010/7/14 Pavel Stehule pavel.steh...@gmail.com:
please, can you refresh patch, please?
Updated patch attached. The latest version is always in the git repo.
http://repo.or.cz/w/pgsql-fdw.git (branch: fdw)
I'm developing the patch on
On 20 July 2010 10:31, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
I am working on to_array, to_string functions and I am looking on
string_to_array function. I am surprised so this function is marked as
immutable
postgres=# select array_to_string(array[current_date],',');
Hello,
I have been redirected here from pg-general.
I tested full text search using GIN index and it turned out that the results
depend on operating system. Not all the rows are found when executing some
of queries on pg server installed on Win XP SP3 and CentOS 5.4, while
everything seems to
On 20 July 2010 10:41, Artur Dabrowski a...@astec.com.pl wrote:
Hello,
I have been redirected here from pg-general.
I tested full text search using GIN index and it turned out that the results
depend on operating system. Not all the rows are found when executing some
of queries on pg
Thom,
please have a look at this message of Oleg Bartunov for details of this
operating system:
http://old.nabble.com/Incorrect-FTS-results-with-GIN-index-tc29172750.html#a29212846
Artur
Thom Brown wrote:
Could you please clarify what you mean by Ubuntu 4.4.1?
Thom
--
Sent via
On 20 July 2010 11:14, Artur Dabrowski a...@astec.com.pl wrote:
Thom,
please have a look at this message of Oleg Bartunov for details of this
operating system:
http://old.nabble.com/Incorrect-FTS-results-with-GIN-index-tc29172750.html#a29212846
Artur
Ah, so gcc 4.4.1 on Ubuntu or
On 7/20/10, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2010-07-18 at 09:42 -0700, David E. Wheeler wrote:
On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
I think there are two ways we can do this, seeing that most appear to be
in favor of doing it in the first place:
On Tue, Jul 20, 2010 at 3:20 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote:
Since it has been over a month since this review was posted and no new
version of the patch has appeared, I think we should mark this patch
as Returned with
Hello
2010/7/20 Itagaki Takahiro itagaki.takah...@gmail.com:
2010/7/14 Pavel Stehule pavel.steh...@gmail.com:
this patch is significantly reduced original patch. It doesn't propose
a simple allocator - just eliminate a high memory usage for ispell
dictionary.
I don't think introducing new
On Tue, 2010-07-20 at 07:06 -0400, Robert Haas wrote:
To me, the definition of a fair shake is that people get 4-5 days to
respond to review comments. This patch has had 33. It's not unfair
to anyone to say, you know, since you didn't get around to updating
this patch for over a month,
Hello
here is a new version - new these functions are not a strict and
function to_string is marked as stable.
both functions share code with older version.
Regards
Pavel
2010/7/16 Brendan Jurd dire...@gmail.com:
On 17 July 2010 04:52, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/7/16
Hi, I've been reviewing this patch for the last few days. Here it is :
* Submission review
* Is the patch in context diff format?
Yes
* Does it apply cleanly to the current CVS HEAD?
Yes
* Does it include reasonable tests, necessary doc patches, etc?
Doc patches are there.
There are no
On Tue, Jul 20, 2010 at 7:41 AM, Simon Riggs si...@2ndquadrant.com wrote:
So focus your effort by leaving this alone until the end of the CF.
Actively terminating things early doesn't help at all with the review
work you mention above, but it looks good if we are measuring cases
resolved per
On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote:
A further point is that it's very difficult to
keep track of progress if the CF page reflects a whole bunch of
supposedly Waiting on Author patches that are really quite
thoroughly dead.
True, but the point under discussion is what to do
Hello
2010/7/16 Jan Urbański wulc...@wulczer.org:
Hi,
here's a review of the \sf and \ef [num] patch from
http://archives.postgresql.org/message-id/162867791003290927y3ca44051p80e697bc6b19d...@mail.gmail.com
== Formatting ==
The patch has some small tabs/spaces and whitespace issues and
On Tue, Jul 20, 2010 at 8:21 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote:
A further point is that it's very difficult to
keep track of progress if the CF page reflects a whole bunch of
supposedly Waiting on Author patches that are really
Working on the git conversion with keywords, and I've noticed a couple of
strange things that don't come up the same way in git. All of these are in
non-code files, but they do defeat the identical tarball mode.
For example, a number of files have commits showing up in cvs with nothing at
all
Robert Haas robertmh...@gmail.com wrote:
we gain something quite specific and tangible, namely, the
expectation that patch authors will stay on top of their patches
if they want them reviewed by the community.
Barring some operational emergency here, I'll be reviewing the
status of all the
Magnus Hagander mag...@hagander.net wrote:
I'm also seeing some entries tagged with vendor branch, such as:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/README
revision 1.1.1.1
Same issue there, the file comes out on the other end with the
wrong keyword (in
On Tue, 2010-07-20 at 09:05 -0400, Robert Haas wrote:
On Tue, Jul 20, 2010 at 8:21 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote:
A further point is that it's very difficult to
keep track of progress if the CF page reflects a whole bunch
Simon Riggs si...@2ndquadrant.com wrote:
I don't think so. We can assume people wrote a patch because they
want it included in Postgres. Bumping them doesn't help them or
us, since there is always an issue other than wish-to-complete.
Not everybody is able to commit time in the way we do and
On Tue, Jul 20, 2010 at 15:31, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Magnus Hagander mag...@hagander.net wrote:
I'm also seeing some entries tagged with vendor branch, such as:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/README
revision 1.1.1.1
Same
On Tue, Jul 20, 2010 at 9:23 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
we gain something quite specific and tangible, namely, the
expectation that patch authors will stay on top of their patches
if they want them reviewed by the community.
On Jul 19, 2010, at 10:40 PM, Robert Haas wrote:
On Wed, Jun 23, 2010 at 9:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 23, 2010 at 9:17 AM, gabrielle gor...@gmail.com wrote:
On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas robertmh...@gmail.com wrote:
Well, that might be a good
Magnus Hagander mag...@hagander.net wrote:
I believe revision 1.1.1.1 is normally seen only for file brought
in through the cvs import command. vendor branch would make
some sense as a commit message for an import.
Yeah, something like that. But why do we for the file above have
one
On Tue, Jul 20, 2010 at 10:00 AM, David Christensen da...@endpoint.com wrote:
Sorry for the delays in response. This is fine; I think there are some
semantic questions that should still be resolved at this point, particularly
if we're moving toward supporting multiple -c and -f lines as
On Tue, Jul 20, 2010 at 12:16 AM, David Christensen da...@endpoint.com wrote:
On Jul 19, 2010, at 11:10 PM, Robert Haas wrote:
On Tue, Jul 20, 2010 at 12:07 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 20, 2010 at 12:02 AM, David Christensen da...@endpoint.com
wrote:
I would
On Tue, Jul 20, 2010 at 5:41 AM, Artur Dabrowski a...@astec.com.pl wrote:
I have been redirected here from pg-general.
I tested full text search using GIN index and it turned out that the results
depend on operating system. Not all the rows are found when executing some
of queries on pg
On Tue, Jul 20, 2010 at 1:57 AM, Zotov zo...@oe-it.ru wrote:
i wrote to
pgsql-b...@postgresql.org
they tell me write to
pgsql-performa...@postgresql.org
they tell me write here
I don`t whant know how optimize query myself (i know it), and i think it
must do planner.
According to the
On Tue, Jul 20, 2010 at 11:40:18AM +0200, Pavel Stehule wrote:
2010/7/20 Itagaki Takahiro itagaki.takah...@gmail.com:
2010/7/14 Pavel Stehule pavel.steh...@gmail.com:
please, can you refresh patch, please?
Updated patch attached. The latest version is always in the git
repo.
Continuing my fun setting up some new Solaris buildfarm critters, I'm
seeing this failure in the dblink test, on 9.0 and 9.1:
gmake[1]: Leaving directory `/export/home/dpage/postgresql/contrib/cube'
gmake[1]: Entering directory `/export/home/dpage/postgresql/contrib/dblink'
gmake -C
Robert Haas robertmh...@gmail.com writes:
All that having been said, I think the issue here is that the query
planner isn't inferring that d1.ID=some constant implies d2.ID=some
constant, even though there's a join clause d1.ID=d2.ID.
I think that's what the Equivalence Classes are for. Or
On Jul 20, 2010, at 9:05 AM, Robert Haas wrote:
On Tue, Jul 20, 2010 at 10:00 AM, David Christensen da...@endpoint.com
wrote:
Sorry for the delays in response. This is fine; I think there are some
semantic questions that should still be resolved at this point, particularly
if we're
On Fri, Jul 16, 2010 at 2:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm not entirely happy with the way I handled the variable-length
struct, although I don't think it's horrible, either. I'm willing to
rework it if someone has a better idea.
I don't
2010/7/20 David Fetter da...@fetter.org:
On Tue, Jul 20, 2010 at 11:40:18AM +0200, Pavel Stehule wrote:
2010/7/20 Itagaki Takahiro itagaki.takah...@gmail.com:
2010/7/14 Pavel Stehule pavel.steh...@gmail.com:
please, can you refresh patch, please?
Updated patch attached. The latest
On 09/02/2010 4:09 PM, Etienne Dube wrote:
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
On Tue, Jul 20, 2010 at 11:23 AM, David Christensen da...@endpoint.com wrote:
Well, IIRC, one of -c and -f suppresses psqlrc, and the other does
not. This doesn't seem very consistent to me, but I'm not sure
there's much to be done about it at this point. I guess if you use
whichever one
On Tue, Jul 20, 2010 at 11:23 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Robert Haas robertmh...@gmail.com writes:
All that having been said, I think the issue here is that the query
planner isn't inferring that d1.ID=some constant implies d2.ID=some
constant, even though there's a
On Tue, Jul 20, 2010 at 11:08 AM, Dave Page dp...@pgadmin.org wrote:
Any ideas?
Are you by any chance running off of the broken git mirror?
http://archives.postgresql.org/pgsql-hackers/2010-07/msg00916.php
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres
Andrew Dunstan and...@dunslane.net wrote:
I despaired of this repo being anything like reliable months ago.
AFAIK it is using a known to be broken version of fromcvs.
Could we have it pull (using git) from the repo you have working
correctly? (Or would that be too Rube Goldbergesque?)
On Tue, Jul 20, 2010 at 4:53 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 20, 2010 at 11:08 AM, Dave Page dp...@pgadmin.org wrote:
Any ideas?
Are you by any chance running off of the broken git mirror?
http://archives.postgresql.org/pgsql-hackers/2010-07/msg00916.php
I might be,
On Tue, Jul 20, 2010 at 4:06 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 20, 2010 at 3:20 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote:
Since it has been over a month since this review was posted and no new
version of the patch
On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Andrew Dunstan and...@dunslane.net wrote:
I despaired of this repo being anything like reliable months ago.
AFAIK it is using a known to be broken version of fromcvs.
Could we have it pull (using git) from
On Tue, Jul 20, 2010 at 18:13, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Andrew Dunstan and...@dunslane.net wrote:
I despaired of this repo being anything like reliable months ago.
AFAIK it is using a known to
Kevin Grittner wrote:
Andrew Dunstan and...@dunslane.net wrote:
I despaired of this repo being anything like reliable months ago.
AFAIK it is using a known to be broken version of fromcvs.
Could we have it pull (using git) from the repo you have working
correctly? (Or would that
On Tue, Jul 20, 2010 at 12:08 PM, Mark Wong mark...@gmail.com wrote:
On Tue, Jul 20, 2010 at 4:06 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 20, 2010 at 3:20 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote:
Since it has been over
Robert Haas robertmh...@gmail.com wrote:
It would result in a massive merge commit and the duplication of
the entire history.
Ah, well, if the two repositories don't share the same IDs, it a
clear no-go. Now that I think about it, it would be a bit much to
expect those to match on
On Tue, Jul 20, 2010 at 18:32, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
It would result in a massive merge commit and the duplication of
the entire history.
Ah, well, if the two repositories don't share the same IDs, it a
clear no-go. Now
Magnus Hagander wrote:
On Tue, Jul 20, 2010 at 18:13, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Andrew Dunstan and...@dunslane.net wrote:
I despaired of this repo being anything like reliable
Tom and, I believe, also Andrew have expressed some concerns about the
space that will be taken up by having multiple copies of the git
repository on their systems. While most users can probably get by
with a single repository, committers will likely need one for each
back-branch that they work
* Robert Haas robertmh...@gmail.com [100720 13:04]:
3. Clone the origin once. Apply patches to multiple branches by
switching branches. Playing around with it, this is probably a
tolerable way to work when you're only going back one or two branches
but it's certainly a big nuisance when
Excerpts from Markus Wanner's message of vie jul 02 19:44:46 -0400 2010:
Having written a very primitive kind of a dynamic memory allocator for
imessages [1], I've always wanted a better alternative. So I've
investigated a bit, refactored step-by-step, and finally came up with
the
Robert Haas robertmh...@gmail.com wrote:
2. Clone the origin n times. Use more disk space. Live with it.
:-)
But each copy uses almost 0.36% of the formatted space on my 150GB
drive!
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Mon, Jul 19, 2010 at 4:08 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/7/19 Tom Lane t...@sss.pgh.pa.us:
I looked into the problem reported here:
http://archives.postgresql.org/pgsql-bugs/2010-07/msg00119.php
[...]
2. Split the processing of aggregates with ORDER
As part of a performance investigation for a customer I've noticed an
O(N^2) performance issue on COMMITs of transactions that contain many
SAVEPOINTs. I've consistently measured COMMIT times of around 9 seconds,
with 49% CPU, mostly in LockReassignCurrentOwner().
BEGIN;
INSERT...
SAVEPOINT ...
Bruce Momjian wrote:
Bruce Momjian wrote:
The attached patch does as suggested. I added the recovery code to the
create tablespace function so I didn't have to duplicate all the code
that computes the path names.
Attached.
Uh, another question. Looking at the createdb
On Tue, Jul 20, 2010 at 1:50 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I'm not sure what kind of resistance you'll see to the idea of a
dynamically allocatable shmem area. Maybe we could use this in other
areas such as allocating space for heavyweight lock objects. Right now
the
On tis, 2010-07-20 at 13:28 -0400, Aidan Van Dyk wrote:
But *all* dependancies need to be proper in the build system, or you
end
up needing a git-clean-type-cleanup between branch switches, forcing a
new configure run too, which takes too much time...
This realization, while true, doesn't
I have some concerns related to the upcoming conversion to git and how
we're going to avoid having things get messy as people start using the
new repository. git has a lot more flexibility and power than CVS,
and I'm worried that it would be easy, even accidentally, to screw up
our history.
1.
Hello Alvaro,
thank you for looking through this code.
On 07/20/2010 07:50 PM, Alvaro Herrera wrote:
Interesting, thanks.
I gave it a skim and found that it badly needs a lot more code comments.
Hm.. yeah, the dynshmem stuff could probably need more comments. (The
bgworker stuff is
Magnus Hagander wrote:
Working on the git conversion with keywords, and I've noticed a couple of
strange things that don't come up the same way in git. All of these are in
non-code files, but they do defeat the identical tarball mode.
For example, a number of files have commits showing up in
On Tue, Jul 20, 2010 at 20:34, Robert Haas robertmh...@gmail.com wrote:
I have some concerns related to the upcoming conversion to git and how
we're going to avoid having things get messy as people start using the
new repository. git has a lot more flexibility and power than CVS,
and I'm
On Tue, Jul 20, 2010 at 20:42, Bruce Momjian br...@momjian.us wrote:
Magnus Hagander wrote:
Working on the git conversion with keywords, and I've noticed a couple of
strange things that don't come up the same way in git. All of these are in
non-code files, but they do defeat the identical
Magnus Hagander wrote:
I have reproduced this by modifying just the CVS tag:
? ? ? ?$PostgreSQL: pgsql/src/backend/catalog/README,v 1.15 2010/07/20
? ? ? ?18:38:53 momjian Exp $
To clarify with what Bruce said on IM to me, the situation is when the
workflow is to manually copy a file
On tis, 2010-06-29 at 12:22 +0100, Mike Fowler wrote:
Mike Fowler wrote:
Thanks again for your help Robert, turns out the fault was in the
pg_proc entry (the 3 up there should've been a two!). Once I took the
grammar out it was quickly obvious where I'd gone wrong.
Attached is a
Hi,
On 07/20/2010 08:23 PM, Robert Haas wrote:
Well, you can't really fix that problem with this infrastructure,
No, but it would allow you to better use the existing amount of shared
memory. Possibly avoiding the problem is certain scenarios.
The failure might
manifest itself in a
Excerpts from Markus Wanner's message of mar jul 20 14:36:55 -0400 2010:
I'm also unconvinced that spinlocks are the best locking primitive here.
Why not lwlocks?
It's derived from a completely lock-free algorithm, as proposed by Maged
M. Michael in: Scalable Lock-Free Dynamic Memory
On tis, 2010-07-20 at 14:34 -0400, Robert Haas wrote:
Right now, it's easy to find all the commits by a particular
committer, and it's easy to see who committed a particular patch, and
the number of distinct committers is pretty small. I'd hate to give
that up.
git log | grep '^Author' |
Someone at OSCON just asked if there is a way to find the _time_ delay
between received and applied WAL. Right now
pg_last_xlog_replay_location() only reports the information in WAL
scale. It would be nice to report that in time, e.g. milliseconds.
Because an idle master will not generate WAL,
On tis, 2010-07-20 at 20:46 +0200, Magnus Hagander wrote:
For one thing, this showed up in a lot of .po files for 8.1.0RC1.
Peter, can you comment on if this coincides with the tools you use to
do those things?
There are/were some games being played with the key words, so this
effect sounds
Hi,
On 07/20/2010 09:05 PM, Alvaro Herrera wrote:
Hmm, deriving code from a paper published by IBM sounds like bad news --
who knows what patents they hold on the techniques there?
Yeah, that might be an issue. Note, however, that the lock-based variant
differs substantially from what's been
On tis, 2010-07-20 at 15:12 +0200, Magnus Hagander wrote:
Working on the git conversion
What's the tool that is being used now? Can you keep us up to date on
the options etc. you plan to use?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Excerpts from Robert Haas's message of mar jul 20 11:48:29 -0400 2010:
That seems sub-optimal; I can see people wanting to use this feature to do
something like:
psql -c 'set work_mem = blah' -f script.sql
and then being surprised when it works differently than just `psql -f
+On Tue, Jul 20, 2010 at 21:15, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-07-20 at 15:12 +0200, Magnus Hagander wrote:
Working on the git conversion
What's the tool that is being used now? Can you keep us up to date on
the options etc. you plan to use?
I'm currently running tests
On tis, 2010-07-20 at 13:04 -0400, Robert Haas wrote:
2. Clone the origin n times. Use more disk space. Live with it. :-)
Well, I plan to use cp -a to avoid cloning over the network n times, but
other than that that was my plan. My .git directory currently takes 283
MB, so I think I can just
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 20, 2010 at 11:23 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
- WHERE (d1.ID=234409763) or (d2.ID=234409763)
+ WHERE (d2.BasedOn=234409763) or (d2.ID=234409763)
I was thinking of the
On tis, 2010-07-20 at 13:31 +0300, Marko Kreen wrote:
http://wiki.postgresql.org/wiki/Standard_conforming_strings
There is two sorts of support:
1. Detect stdstr on startup and use that setting.
2. Detect online changes to stdstr and follow them.
AFAICS psycopg does not support 2).
On Jul 20, 2010, at 2:18 PM, Alvaro Herrera wrote:
Excerpts from Robert Haas's message of mar jul 20 11:48:29 -0400 2010:
That seems sub-optimal; I can see people wanting to use this feature to do
something like:
psql -c 'set work_mem = blah' -f script.sql
and then being surprised
Robert Haas wrote:
Tom and, I believe, also Andrew have expressed some concerns about the
space that will be taken up by having multiple copies of the git
repository on their systems. While most users can probably get by
with a single repository, committers will likely need one for each
On Sat, Jul 17, 2010 at 01:15:22AM +0900, Hitoshi Harada wrote:
2010/7/17 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
is exsiting one that work with single tuplestore, it
On Fri, Jul 16, 2010 at 12:15 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/7/17 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
is exsiting one that work with single
On Tue, Jul 20, 2010 at 2:42 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Jul 20, 2010 at 20:34, Robert Haas robertmh...@gmail.com wrote:
I have some concerns related to the upcoming conversion to git and how
we're going to avoid having things get messy as people start using the
new
On Tue, Jul 20, 2010 at 3:12 PM, Peter Eisentraut pete...@gmx.net wrote:
Well, I had looked forward to actually putting the real author into the
author field.
What if there's more than one? What if you make changes yourself?
How will you credit the reviewer?
--
Robert Haas
EnterpriseDB:
Excerpts from Markus Wanner's message of mar jul 20 14:54:42 -0400 2010:
With respect to imessages specifically, what is the motivation for
using shared memory rather than something like an SLRU? The new
LISTEN implementation uses an SLRU and handles variable-size messages,
so it seems
Top posting. On purpose. :p
This patch seems to be foundering in a sea of opinions. It seems
that everybody wants to do *something* about this, but what?
For one more opinion, my shop has chosen to never touch the default
postgresql.conf file any more, beyond adding one line to the bottom
On Jul 20, 2010, at 5:00 PM, Kevin Grittner wrote:
Top posting. On purpose. :p
This patch seems to be foundering in a sea of opinions. It seems
that everybody wants to do *something* about this, but what?
For one more opinion, my shop has chosen to never touch the default
Robert Haas wrote:
I have some concerns related to the upcoming conversion to git and how
we're going to avoid having things get messy as people start using the
new repository. git has a lot more flexibility and power than CVS,
and I'm worried that it would be easy, even accidentally, to
David Christensen da...@endpoint.com wrote:
On Jul 20, 2010, at 5:00 PM, Kevin Grittner wrote:
my shop has chosen to never touch the default postgresql.conf
file any more, beyond adding one line to the bottom of it which
is an include directive, to bring in our overrides.
So you'll now
On Tue, Jul 20, 2010 at 5:46 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Markus Wanner's message of mar jul 20 14:54:42 -0400 2010:
With respect to imessages specifically, what is the motivation for
using shared memory rather than something like an SLRU? The new
(2010/07/21 7:33), Kevin Grittner wrote:
David Christensenda...@endpoint.com wrote:
On Jul 20, 2010, at 5:00 PM, Kevin Grittner wrote:
my shop has chosen to never touch the default postgresql.conf
file any more, beyond adding one line to the bottom of it which
is an include directive, to
On Tue, Jul 20, 2010 at 6:00 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
What will make everyone happy here?
Nothing.
But on a more serious note, the basic dilemma with this patch is
whether it's useful enough to justify the extra code. I think it's
pretty clearly harmless (modulo
Robert Haas wrote:
On Tue, Jul 20, 2010 at 3:12 PM, Peter Eisentraut pete...@gmx.net wrote:
Well, I had looked forward to actually putting the real author into the
author field.
What if there's more than one? What if you make changes yourself?
How will you credit the reviewer?
On Tue, Jul 20, 2010 at 5:13 PM, Merlin Moncure mmonc...@gmail.com wrote:
2. Use temp table instead of tuplestore list. Since we agreed we need
to execute each plan one by one starting and shutting down executor,
it now looks very simple strategy.
I didn't look at this because I thought using
On Tue, Jul 20, 2010 at 3:13 PM, Bruce Momjian br...@momjian.us wrote:
Someone at OSCON just asked if there is a way to find the _time_ delay
between received and applied WAL. Right now
pg_last_xlog_replay_location() only reports the information in WAL
scale. It would be nice to report that
1 - 100 of 110 matches
Mail list logo
