Hello Dilip,
Query: select count(*) from t1,t2 where t1.b 12000;
>
> Test Result:
> Nest Loop Join with Index Scan : 1653.506 ms
> Sort Merge Join for (seq scan) : 610.257ms
>
>
This looks like a great improvement. Repeating Nicolas's question, d
Hi,
When array of char * is used as target for the FETCH statement returning
more than one row, it tries to store all the result in the first element.
PFA test_char_select.pgc, which fetches first 3 relnames from pg_class
ordered by relname. The program prints following result
steps to compile and
Hello,
You can find attached a small patch to fix the pg_replication_slots
documentation. The slot_type and plugin are not in the appropriate
order, slot_name and plugin have a wrong type and xmin appears two times.
Regards
--
Thomas Reiss
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/
--On 26. April 2014 19:42:47 -0700 Peter Geoghegan wrote:
I suggest removing it for 9.5, and instead logging individual
occurrences of backend fsync requests within ForwardFsyncRequest(). It
seems fair to treat that as an anomaly to draw particular attention
to.
But wouldn't that make it mo
On Tue, Apr 29, 2014 at 2:51 AM, Bernd Helmle wrote:
>> I suggest removing it for 9.5, and instead logging individual
>> occurrences of backend fsync requests within ForwardFsyncRequest(). It
>> seems fair to treat that as an anomaly to draw particular attention
>> to.
>
> But wouldn't that make i
On Tue, Apr 29, 2014 at 2:52 AM, Peter Eisentraut wrote:
> Please fix this compiler warning. I think it came from this patch.
Oops, I fixed it in a previous version but didn't notice it had crept
back in in the back-and-forth. Will do.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-
On Tue, Apr 29, 2014 at 5:54 AM, Peter Geoghegan wrote:
> On Tue, Apr 29, 2014 at 2:51 AM, Bernd Helmle wrote:
>>> I suggest removing it for 9.5, and instead logging individual
>>> occurrences of backend fsync requests within ForwardFsyncRequest(). It
>>> seems fair to treat that as an anomaly to
Robert Haas writes:
> Overall, I don't see much reason to tinker with this. If we had no
> reporting at all of this condition now, I'd probably be mildly more
> supportive of adding a log message than a counter. But since we've
> already got something and there's no real problem with it, I'm
> d
On Sun, Feb 3, 2013 at 4:06 PM, Tom Lane wrote:
> "Marko Tiikkaja" writes:
> > Here's the third version of this patch, hopefully this time without any
> > problems. I looked through the patch and it looked OK, but I did that
> > last time too so I wouldn't trust myself on that one.
>
> Applied
On 4/29/14 4:29 PM, Keith Fiske wrote:
Was this ever committed into core? Apologies, I'm not very familiar with
looking through the commit history of the source code and I don't see
anything about this option or pretty-print outputs in the pg_dump/restore
docs for 9.3. Had someone asking me about
On 04/29/2014 02:56 AM, Heikki Linnakangas wrote:
On 04/28/2014 10:32 PM, Tom Lane wrote:
Robert Haas writes:
I have to admit it's been a few years since I've had to play with
WAL_DEBUG, so I don't really remember what I was trying to do. But I
don't see any real argument that three slash-se
Andrew Dunstan writes:
> On 04/29/2014 02:56 AM, Heikki Linnakangas wrote:
>> On 04/28/2014 10:32 PM, Tom Lane wrote:
>>> Meh. I still think it's a bad idea to have CATALOG_VERSION_NO getting
>>> compiled into libpgcommon.a, where there will be no way to cross-check
>>> that it matches anything.
Keith Fiske writes:
> On Sun, Feb 3, 2013 at 4:06 PM, Tom Lane wrote:
>> Applied with corrections.
> Was this ever committed into core? Apologies, I'm not very familiar with
> looking through the commit history of the source code and I don't see
> anything about this option or pretty-print outpu
Hi,
There's a repeated pattern of
Assert(IsA(ptr, nodetype));
foo = (nodetype *) ptr;
how about adding a castNode() that combines those? Something like:
#if !defined(USE_ASSERT_CHECKING)
#define castNode(nodeptr,_type_) \
((_type_ *) (nodeptr))
#elif defined(__GNUC__)
#define castNod
Greetings,
This is take-2 on this. Apologies for the short notice.
As some may be aware, we are currently working with Rackspace to
upgrade the PostgreSQL infrastructure systems which they graciously
host for us. As part of these upgrades there will be downtime for
systems hosted ther
On Tue, Apr 29, 2014 at 11:14 AM, Tom Lane wrote:
> Keith Fiske writes:
> > On Sun, Feb 3, 2013 at 4:06 PM, Tom Lane wrote:
> >> Applied with corrections.
>
> > Was this ever committed into core? Apologies, I'm not very familiar with
> > looking through the commit history of the source code and
Andres Freund writes:
> There's a repeated pattern of
> Assert(IsA(ptr, nodetype));
> foo = (nodetype *) ptr;
> how about adding a castNode() that combines those?
Doesn't really seem worth it. The notational advantage is not great,
and to the extent that it were to touch a lot of places, the m
Huh, I had assumed this was old behaviour. I didn't realize this was
new with 9.3.
Considering the thread "pg_get_viewdefs() indentation considered
harmful" I'm beginning to think this was a regression. It results in
some dump files being unnecessarily large and the pg_dump consuming
too much memo
Greg Stark writes:
> Huh, I had assumed this was old behaviour. I didn't realize this was
> new with 9.3.
> Considering the thread "pg_get_viewdefs() indentation considered
> harmful" I'm beginning to think this was a regression. It results in
> some dump files being unnecessarily large and the p
Hi,
On win32, initdb fails if it's path includes a space and at ('@')
character. E.g.
C:\>"C:\Program Files\user@company\Postgres\9.3\bin\initdb.exe" -D "c:\baz"
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
Here's a patch that fixes initdb by
Given the following code.
PGconn* const conn=PQconnectdbParams(keywords, values, false);
if(! conn || PQstatus(conn)!=CONNECTION_OK){ /* error code? */ }
- In case of a failed connection is there a way to get the error code to be
able to distinguish between a (e.g.) bad password and the server be
Greg Stark writes:
> I propose the attached patch. It wraps at 40 and also divides the
> indent level by half the std indent level. I tried a few different
> combinations and this is the one that produced the output I liked
> best.
I doubt you can do that (the half-size-step bit), at least not wi
... so let's stop using that phrase, OK?
http://meyerweb.com/eric/comment/chech.html
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On 04/29/2014 09:14 PM, Nikhil Deshpande wrote:
On win32, initdb fails if it's path includes a space and at ('@')
character. E.g.
C:\>"C:\Program Files\user@company\Postgres\9.3\bin\initdb.exe" -D "c:\baz"
'C:\Program' is not recognized as an internal or external command,
operable program or bat
On 4/17/14, 9:38 AM, Tom Lane wrote:
But the ability to easily spin up temporary branches for testing would
>>also be great. Unfortunately, I suspect that only a minority of the
>>buildfarm owners would choose to participate, which would make it less
>>useful, but if we could solve that problem
On 4/26/14, 9:42 PM, Peter Geoghegan wrote:
Backend fsyncs are theoretically still possible after the fsync
request queue compaction patch (which was subsequently back-patched to
all supported release branches). However, I'm reasonably confident
that that patch was so effective as to make a backe
On Tue, Apr 29, 2014 at 9:11 PM, Jim Nasby wrote:
> On 4/17/14, 9:38 AM, Tom Lane wrote:
>
>> But the ability to easily spin up temporary branches for testing would
>>also be great. Unfortunately, I suspect that only a minority of the
>>buildfarm owners would choose to participate, whi
On Tue, Apr 29, 2014 at 12:02 PM, Jim Nasby wrote:
> All else equal, I don't like the idea of removing this from
> pg_stat_bgwriter. Being able to look there and see if this is occurring
> since last stats reset is much easier than grepping logfiles.
Have you ever actually seen it at a non-zero v
All,
We have confirmation from Rackspace that the maintenance will begin in
~5 minutes.
Thanks!
Stephen
* Stephen Frost (sfr...@snowman.net) wrote:
> Greetings,
>
> This is take-2 on this. Apologies for the short notice.
>
> As some may be aware, we are curren
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Here's a draft patch tackling point 1. This gets rid of a whole lot
> of parenthesization, as well as indentation, for simple UNION lists.
> You can see the results in the changed regression test outputs.
[...]
> Comments?
+1.
Thanks,
Hello World writes:
> Given the following code.
> PGconn* const conn=PQconnectdbParams(keywords, values, false);
> if(! conn || PQstatus(conn)!=CONNECTION_OK){ /* error code? */ }
> - In case of a failed connection is there a way to get the error code to be
> able to distinguish between a (e.g.)
Josh Berkus writes:
> ... so let's stop using that phrase, OK?
> http://meyerweb.com/eric/comment/chech.html
Shrug ... what I see there is a rant from a guy with no sense of humor.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Josh Berkus writes:
> > ... so let's stop using that phrase, OK?
> > http://meyerweb.com/eric/comment/chech.html
>
> Shrug ... what I see there is a rant from a guy with no sense of humor.
+1
'pt', I say.
Thanks,
Stephen
s
Heikki Linnakangas writes:
> This looks correct to me. popen() requires SYSTEMQUOTEs on Windows, like
> system() does. We already use SYSTEMQUOTEs in some popen() calls, like
> in pg_ctl, but initdb is missing them. get_bin_version function in
> pg_upgrade is also missing it, as is the popen()
On Tue, Apr 29, 2014 at 7:46 PM, Tom Lane wrote:
> I doubt you can do that (the half-size-step bit), at least not without
> a much larger patch than this: there are assorted places that just
> unconditionally append PRETTYINDENT_STD spaces, and would have to be
> taught to do something different.
Greg Stark writes:
> Actually the only thing that might want to be adjusted is the
> indentation in the beginning of the setop (ruleutils.c:4720) which is
> what causes that long line of parentheses at the beginning of the
> example. I suppose in an ideal world it would start following the
> reduc
On Wed, Apr 30, 2014 at 3:57 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> This looks correct to me. popen() requires SYSTEMQUOTEs on Windows, like
>> system() does.
It seems right now SYSTEMQUOTE is used before popen both for
Windows and non-Windows, ex. adjust_data_dir() in pg_ctl.c
>
Amit Kapila writes:
> On Wed, Apr 30, 2014 at 3:57 AM, Tom Lane wrote:
>> We might forget to use the wrapper function too, if it has a nonstandard
>> name, no? A better idea would be to redefine popen() and system() on
>> Windows. It looks like we're already using a #define to redefine popen().
On Wed, Apr 30, 2014 at 6:33 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Here's a draft patch tackling point 1. This gets rid of a whole lot
>> of parenthesization, as well as indentation, for simple UNION lists.
>> You can see the results in the changed regression test o
On 04/30/2014 01:27 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Josh Berkus writes:
... so let's stop using that phrase, OK?
http://meyerweb.com/eric/comment/chech.html
Shrug ... what I see there is a rant from a guy with no sense of humor.
+1
'pt', I say.
I wasn
40 matches
Mail list logo
