Hi,
On Sat, Jan 10, 2009 at 10:42 PM, Simon Riggs wrote:
>
> On Sat, 2009-01-10 at 19:16 +0900, Fujii Masao wrote:
>
>> On Thu, Dec 18, 2008 at 9:55 AM, Simon Riggs wrote:
>> >> 4. sleeping
>> >> http://archives.postgresql.org/pgsql-hackers/2008-12/msg00438.php
>> >>
>> >> I'm looking for the be
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 shoul
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
Description
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 docume
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 y
> 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
> te
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
On Sat, Jan 10, 2009 at 01:57:27PM -0500, Gregory Stark wrote:
> Tom Lane writes:
>
> > Jeff Davis 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.
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 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
> > > i
2009/1/10 Heikki Linnakangas :
> 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, maybe Peter.
Pavel
> --
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 http://momjian.us
EnterpriseDB http://enterprisedb.com
Magnus Hagander wrote:
> Tom Lane wrote:
> > Magnus Hagander 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 connection
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
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
> 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,
Tom Lane wrote:
> Peter Eisentraut 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 sa
Tom Lane writes:
> Jeff Davis 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
>
On Sat, 2009-01-10 at 13:36 -0500, Tom Lane wrote:
> Jeff Davis 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 carefull
Peter Eisentraut 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 any of a milli
Jeff Davis 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 is whether the
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 m
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
> neede
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
> > bench
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 Sat, 2009-01-10 at 19:16 +0900, Fujii Masao wrote:
> On Thu, Dec 18, 2008 at 9:55 AM, Simon Riggs 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 reduce the
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 m
> 2009/1/10 Tom Lane :
>> Bruce Momjian 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 expected so RETURN
--On Freitag, Januar 09, 2009 17:53:31 +0100 Bernd Helmle
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 and so the new files
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 com
On Fri, 9 Jan 2009 22:46:06 -0500 (EST)
Greg Smith 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 in Trac
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 wrote:
>> 4. sleeping
>> http://archives.postgresql.
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. Thi
Hello
2009/1/10 Tom Lane :
> Bruce Momjian 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 SELECT LOOP
RETURN NEXT patt
33 matches
Mail list logo
