Hello
2009/1/10 Tom Lane t...@sss.pgh.pa.us:
Bruce Momjian br...@momjian.us writes:
Uh, is this ready to be applied?
I don't think any consensus has been reached on changing this behavior.
regards, tom lane
I thing, so this is bug - RETURN QUERY has to supply FOR
On Thu, 2009-01-08 at 20:30 +0200, Heikki Linnakangas wrote:
Since I've been whining about that for some time, I figured I have to
put my money where my mouth is, so here's a patch based on v6a that
eliminates the concept of slotids, as well as the new xl_info2 field in
XLogRecord. This
Hi,
I attached the updated version of Synch Rep patch (v5) on wiki.
The description of User Overview is also already updated.
http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects#Synch_Rep
On Thu, Dec 18, 2008 at 9:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
4. sleeping
On Fri, 9 Jan 2009 22:46:06 -0500 (EST)
Greg Smith gsm...@gregsmith.com wrote:
On Fri, 9 Jan 2009, D'Arcy J.M. Cain wrote:
. is on the long list of characters to be escaped I sent out earlier.
I tried escaping the '.' but it didn't change the behaviour.
I did try that specific exapmle
On Sat, 2009-01-10 at 09:40 +, Simon Riggs wrote:
This leads to an error when we SubTransSetParent(child_xid, top_xid);
since this assumes that the top_xid is the parent, which it is not.
Mostly you wouldn't notice unless you were looking up the subtrans
status for an xid that had
--On Freitag, Januar 09, 2009 17:53:31 +0100 Bernd Helmle
maili...@oopsware.de wrote:
I've decided to check updatability of all involved views during view
creation. Please find attached a new version with all other open issues
adressed.
Oops, forgot to track some files in my new git branch
2009/1/10 Tom Lane t...@sss.pgh.pa.us:
Bruce Momjian br...@momjian.us writes:
Uh, is this ready to be applied?
I don't think any consensus has been reached on changing this behavior.
I thing, so this is bug - RETURN QUERY has to supply FOR SELECT LOOP
RETURN NEXT pattern.
My first patch
On Sat, 2009-01-10 at 19:16 +0900, Fujii Masao wrote:
I attached the updated version of Synch Rep patch (v5) on wiki.
The description of User Overview is also already updated.
http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects#Synch_Rep
Looks good on initial read of Wiki. Few minor
On Sat, 2009-01-10 at 19:16 +0900, Fujii Masao wrote:
On Thu, Dec 18, 2008 at 9:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
4. sleeping
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00438.php
I'm looking for the better idea. How should we resolve that problem?
Only
Hi.
My swift attack test was the MinGW environment.
But, Inoue-san suggestion.
1. MinGW+gcc build
HIROSHI=# set LC_TIME=Ja;
SET
HIROSHI=# select to_char(now(),'TMDay');
to_char
-
日曜日
(1 行)
HIROSHI=# set LC_TIME='Japan';
SET
HIROSHI=# select to_char(Now(),'TMDay');
to_char
-
日曜日
On Fri, Jan 09, 2009 at 02:00:39PM -0800, Jeff Davis wrote:
On Fri, 2009-01-09 at 14:29 -0600, Kenneth Marshall wrote:
Jeff,
Thanks for the review. I would not really expect any differences in hash
index build times other than normal noise variances. The most definitive
benchmark that
On Sat, 2009-01-10 at 11:06 -0600, Kenneth Marshall wrote:
Separating mix() and final() should have some performance benefit,
right?
Yes, it does but the results can be swamped by other latencies in the
code path. Tests such as Tom's benchmark of the underlying functions is
needed to
Pavel Stehule wrote:
My first patch expected so RETURN QUERY is final statement, so I don't
solve FOUND variable, but Heikki changed this behave.
Me? I don't recall doing anything related to this.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers
Jeff Davis pg...@j-davis.com writes:
I ran 5 times on both old and new code, eliminating the top and bottom
and taking the average of the remaining 3, and I got a 6.9% performance
improvement with the new code.
The question that has been carefully evaded throughout the discussion
of this patch
Peter Eisentraut pete...@gmx.net writes:
The way I read this is that this was a temporary kernel/libc mismatch in
a development version of Debian 3 years ago that was fixed within 2
months of being reported and was never released to the general public.
So it would be on the same level as
On Sat, 2009-01-10 at 13:36 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
I ran 5 times on both old and new code, eliminating the top and bottom
and taking the average of the remaining 3, and I got a 6.9% performance
improvement with the new code.
The question that has been
Tom Lane t...@sss.pgh.pa.us writes:
Jeff Davis pg...@j-davis.com writes:
I ran 5 times on both old and new code, eliminating the top and bottom
and taking the average of the remaining 3, and I got a 6.9% performance
improvement with the new code.
The question that has been carefully evaded
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
The way I read this is that this was a temporary kernel/libc mismatch in
a development version of Debian 3 years ago that was fixed within 2
months of being reported and was never released to the general public.
So it would be on
I think at a minimum there should be a manual configuration switch
(ie something in pg_config_manual.h) to allow the builder to disable
use of posix_fadvise, even if configure thinks it's there. Depending
on buildfarm results we may have to do more than that.
This seems pretty pointless,
On Sat, 2009-01-10 at 13:57 -0500, Gregory Stark wrote:
But I gather it's a 6% speedup in the time spent actually in the
hash function.
That's correct. I was not able to detect any difference at all between
the old and new code using HashAggregate, which is where most of my
testing effort went:
Tom, et al,
* Stephen Frost (sfr...@snowman.net) wrote:
applyColumnPrivs is misnamed as it's not applying any privileges nor
indeed doing much of anything directly to do with privileges. It should
probably be named something more like findReferencedColumns. And what's
with the special
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Any reason not to just have the environment variable documentation refer
back to the connection option documentation?
Well, not all of 'em are connection options.
I could see documenting the
I often get confused about how to do linking in SGML so I wrote up
/doc/src/sgml/README.links and added the file to CVS. Peter, would you
review it and make any improvements? Thanks.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
2009/1/10 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Pavel Stehule wrote:
My first patch expected so RETURN QUERY is final statement, so I don't
solve FOUND variable, but Heikki changed this behave.
Me? I don't recall doing anything related to this.
I have to look to archive,
On Sat, Jan 10, 2009 at 10:56:15AM -0800, Jeff Davis wrote:
On Sat, 2009-01-10 at 13:36 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
I ran 5 times on both old and new code, eliminating the top and bottom
and taking the average of the remaining 3, and I got a 6.9%
On Sat, Jan 10, 2009 at 01:57:27PM -0500, Gregory Stark wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Jeff Davis pg...@j-davis.com writes:
I ran 5 times on both old and new code, eliminating the top and bottom
and taking the average of the remaining 3, and I got a 6.9% performance
In thinking about how to communicate to users about reducing continuous
archiving storage requirements, I realized we don't mention pglesslog in
our official documentation.
The attached patch documents how to use pglesslog and gzip/gunzip to
reduce storage requirements. Comments?
Also, I assume
Here is the patch that replace pg_autovaccum catalog with reloptions. I
refactored the reloptions.c to support multiple parameters and made the
action of adding a new option an easy task. I'm testing it yet, so don't
expect it to work properly. I'll prepare docs as soon as I finish the
tests.
On Sat, 2009-01-10 at 11:45 +, Simon Riggs wrote:
On Sat, 2009-01-10 at 09:40 +, Simon Riggs wrote:
This leads to an error when we SubTransSetParent(child_xid, top_xid);
since this assumes that the top_xid is the parent, which it is not.
Mostly you wouldn't notice unless you were
On Sat, 2009-01-10 at 21:09 -0500, Bruce Momjian wrote:
Comments?
If this is for backpatching, it makes sense. We should at least wait
until sync rep is accepted or rejected and docs written.
In general I don't think we should refer/link to other companies'
copyrighted materials in our
Tom Lane committed some parts of the posix_fadvise patch today; here
is my attempt at a re-merged version for the benefit of anyone
attempting to do performance testing, etc. It passes regression tests
but I haven't tested it much beyond that.
...Robert
posix_fadvise_v23_rh2.diff.gz
Simon Riggs wrote:
On Sat, 2009-01-10 at 21:09 -0500, Bruce Momjian wrote:
Comments?
If this is for backpatching, it makes sense. We should at least wait
until sync rep is accepted or rejected and docs written.
No, it is not for backpatching.
In general I don't think we should
Hi,
On Sat, Jan 10, 2009 at 10:42 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2009-01-10 at 19:16 +0900, Fujii Masao wrote:
On Thu, Dec 18, 2008 at 9:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
4. sleeping
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00438.php
33 matches
Mail list logo
