On 2013-02-08 15:15, Andrew Dunstan wrote:
Revised patch attached. The problem also existed with the get*_as_text
functions (and their operators). Some additional regression tests are
added to test these cases.
Hi,
I did some minor things with the patch today.
1. thanks for the work on t
On Sun, Feb 10, 2013 at 3:25 AM, Alvaro Herrera
wrote:
> Magnus Hagander escribió:
>> On Sat, Feb 9, 2013 at 4:31 PM, Peter Geoghegan
>> wrote:
>> > On 9 February 2013 15:24, Magnus Hagander wrote:
>> >> It's in your personal majordomo settings. I don't think it's related
>> >> to that at all, b
2013/2/10 Dean Rasheed :
> On 9 February 2013 18:30, Pavel Stehule wrote:
> There are a new question
>
> what should be result of
>
> format(">>%2$*1$s<<", NULL, "hello")
>
> ???
>>>
>>> My first thought is that a NULL width should be treated the same as no
>>> width at
On 02/10/2013 05:43 AM, Yeb Havinga wrote:
On 2013-02-08 15:15, Andrew Dunstan wrote:
Revised patch attached. The problem also existed with the
get*_as_text functions (and their operators). Some additional
regression tests are added to test these cases.
Hi,
I did some minor things with
David Fetter writes:
> Per suggestions and lots of help from Andrew Gierth, please find
> attached a patch to clean up the call sites for FuncCall nodes, which
> I'd like to expand centrally rather than in each of the 37 (or 38, but
> I only redid 37) places where it's called. The remaining one i
On Sun, Feb 10, 2013 at 10:09:19AM -0500, Tom Lane wrote:
> David Fetter writes:
> > Per suggestions and lots of help from Andrew Gierth, please find
> > attached a patch to clean up the call sites for FuncCall nodes, which
> > I'd like to expand centrally rather than in each of the 37 (or 38, but
On Thu, Feb 7, 2013 at 7:45 AM, Etsuro Fujita
wrote:
> Through the work on the patch [1], I had a question about the psql \copy
> command. We are permitted 1) but not permitted 2):
> 1) \copy foo from stdin ;
> 2) \copy foo from stdin;
> Is this intentional? I think it would be better to allow f
On Fri, Feb 8, 2013 at 1:56 PM, Ivan Lezhnjov IV wrote:
> Hello,
>
> I'd like to submit the following patch that extends backup.sgml with a bit of
> practical but important information.
>
> Project: postgresql
> Patch filename: backup.sgml-cmd-v001.patch
>
> The patch extends backup.sgml and adds
On Wed, Jan 30, 2013 at 10:00:01AM +0400, Alexander Law wrote:
> 30.01.2013 05:51, Noah Misch wrote:
>> On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
>>> Alexander Law writes:
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@gmail.c
On Fri, Feb 8, 2013 at 1:07 PM, Phil Sorber wrote:
> On Fri, Feb 8, 2013 at 12:46 PM, Fujii Masao wrote:
>> No maybe. But I think that all the client commands should follow the
>> same rule. Otherwise a user would get confused when specifying
>> options.
>
> I would consider the rest of the apps
Robert Haas wrote:
> I'm not sure what others think, but the proposed wording seems a
> bit hard on plain text dumps to me.
Agreed. I don't know how many times I've piped the output of
pg_dump to the input of psql. Certainly that was very common
before pg_upgrade was available. And for develo
Robert Haas writes:
> I'm not sure what others think, but the proposed wording seems a bit
> hard on plain text dumps to me.
I wasn't terribly thrilled with labeling pg_dumpall "deprecated",
either. It might be imperfect for some use cases, but that adjective
suggests that we're trying to get ri
While looking at some proposed patches and pondering some questions on
performance, I realized I desperately needed ways to run benchmarks with
different settings without needing to edit postgresql.conf and
restart/reload the server each time.
Most commonly, I want to run with synchronous_commit o
On 10 February 2013 23:27, Jeff Janes wrote:
> While looking at some proposed patches and pondering some questions on
> performance, I realized I desperately needed ways to run benchmarks with
> different settings without needing to edit postgresql.conf and
> restart/reload the server each time.
Noah Misch writes:
> Following some actual testing, I see that we treat postgresql.conf values as
> byte sequences; any reinterpretation as encoded text happens later. Hence,
> contrary to my earlier suspicion, your patch does not make that situation
> worse. The present situation is bad; among
Pavel Stehule writes:
> In Czech discussion group was reported performance regression of CTE
> query. I wrote a test, when I can show it.
I don't see anything tremendously wrong here. The older branches are
choosing the right plan for entirely wrong reasons: they don't notice
that "select foo(a)
Hi PostgreSQL hackers,
I often need to calculate time to spend for index creation and vacuum
to analyze PostgreSQL data load performance. Index creation and vacuum
will take non trivial time for large scale data and it is important
information of data loading benchmark.
So I would like to propose
On Sat, Feb 9, 2013 at 5:09 PM, Euler Taveira wrote:
> On 09-02-2013 13:45, Gurjeet Singh wrote:
> > BTW, I hope I understand what selfcopy is: send a copy to yourself. Why
> would
> > that be turned on by default?
> >
> If you want to reply to yourself...
Wouldn't I be using the copy in my "se
Magnus Hagander escribió:
> On Sun, Feb 10, 2013 at 3:25 AM, Alvaro Herrera
> wrote:
> > I changed the defaults for new subscribers, and also the flags values
> > for all existing subscribers, note.
>
> For *all* existing subscribers, or those that had not changed their
> defaults? And did you c
2013/2/11 Tom Lane :
> Pavel Stehule writes:
>> In Czech discussion group was reported performance regression of CTE
>> query. I wrote a test, when I can show it.
>
> I don't see anything tremendously wrong here. The older branches are
> choosing the right plan for entirely wrong reasons: they do
>
> no, there is strange estimation
>
> -> Seq Scan on public.x2 (cost=0.00..345560.00 rows=500
> width=4) (actual time=17.914..9330.645 rows=133 loops=1)
>Output: x2.a
>Filter: (NOT (SubPlan 2))
>Rows Removed by Filter: 867
>
Hi,
Any review comments on this ?
On Tue, Jan 29, 2013 at 6:03 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
> Hi Heikki,
>
>
> On Mon, Jan 28, 2013 at 2:34 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> On 23.01.2013 17:30, Robert Haas wrote:
>>
>>> On Wed, Jan 23
22 matches
Mail list logo
