On Mon, Sep 8, 2014 at 10:39 AM, Amit Kapila
wrote:
>
> On Sat, Jul 26, 2014 at 9:32 PM, Robert Haas
wrote:
> > On Fri, Jul 25, 2014 at 4:16 PM, Alvaro Herrera
> > wrote:
> > > On Fri, Jul 25, 2014 at 02:11:32PM -0400, Robert Haas wrote:
> > >> + pq_mq_busy = true;
> > >> +
> > >> + iov[
On Sat, Jul 26, 2014 at 9:32 PM, Robert Haas wrote:
> On Fri, Jul 25, 2014 at 4:16 PM, Alvaro Herrera
> wrote:
> > On Fri, Jul 25, 2014 at 02:11:32PM -0400, Robert Haas wrote:
> >> + pq_mq_busy = true;
> >> +
> >> + iov[0].data = &msgtype;
> >> + iov[0].len = 1;
> >> + iov[1].data
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> ignore_nulls in array_to_json_pretty probably is not necessary. On second
> hand, the cost is zero, and we can have it for API consistency.
I'm willing to be persuaded either way on this, really. I do think it
would be nice for both array_to_json
* Vik Fearing (vik.fear...@dalibo.com) wrote:
> On 09/02/2014 10:17 PM, Marko Tiikkaja wrote:
> > Yeah, I think I like this better than allowing all of them without the
> > database name.
>
> Why? It's just a noise word!
Eh, because it ends up reindexing system tables too, which is probably
not
Hi
2014-09-08 5:48 GMT+02:00 Stephen Frost :
> Pavel, All,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > Thank you
>
> I made a few minor adjustments, but the bigger issue (in my view) is
> what to do about array_to_json_pretty- seems like we should do the same
> there, no? Perhaps yo
On Sun, Sep 7, 2014 at 10:36 AM, Marko Tiikkaja wrote:
> On 2014-09-07 19:28, Jeff Janes wrote:
>
>>
>> select pgp_sym_decrypt(dearmor('-BEGIN PGP MESSAGE-
>> Version: GnuPG v2.0.14 (GNU/Linux)
>> Password: foobar
>>
>> jA0EBwMCqywsAv/hXJ7D0j8BWsD+9H7DY4KhrIIw2oV/6tBueVQ28+VDjBw9rGiy
>> 3
Pavel, All,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> Thank you
I made a few minor adjustments, but the bigger issue (in my view) is
what to do about array_to_json_pretty- seems like we should do the same
there, no? Perhaps you could propose a new patch which incorporates my
minor chang
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2014-07-23 8:38 GMT+02:00 Tomas Vondra :
> > OK, thanks. The new version seems OK to me.
>
> Thank you
I've started looking over the patch and went back through the previous
thread about it. For my part, I'm in favor of adding this capab
Kouhei Kaigai writes:
> The documentation says that return type of sum(expression) is...
> bigint for smallint or int arguments, numeric for bigint arguments,
> double precision for floating-point arguments, otherwise the same
> as the argument data type
> Does it expect sum(float4) returns
Hello,
http://www.postgresql.org/docs/devel/static/functions-aggregate.html
The documentation says that return type of sum(expression) is...
bigint for smallint or int arguments, numeric for bigint arguments,
double precision for floating-point arguments, otherwise the same
as the argument
(2014/09/05 0:56), Bruce Momjian wrote:> On Thu, Sep 4, 2014 at
08:41:43PM +0530, Atri Sharma wrote:
>> On Thursday, September 4, 2014, Bruce Momjian wrote:
>>
>> On Thu, Sep 4, 2014 at 08:37:08AM -0400, Robert Haas wrote:
>> > The main problem I see here is that accurate costing may
(2014/09/04 21:37), Robert Haas wrote:> On Wed, Sep 3, 2014 at 5:16 AM,
Shigeru Hanada wrote:
>> (1) Separate cost estimation phases?
>> For existing join paths, planner estimates their costs in two phaeses.
>> In the first phase initial_cost_foo(), here foo is one of
>> nestloop/mergejoin/hashj
hello. i recode vacuum for gist index.all tests is ok.also i test vacuum on table size 2 million rows. all is ok.on my machine old vaccum work about 9 second. this version work about 6-7 sec .review please. thanks.*** a/src/backend/access/gist/gistvacuum.c
--- b/src/backend/access/gist/gistvacuum.c
On 07/09/14 21:09, Andres Freund wrote:
On 2014-09-07 15:05:35 -0400, Tom Lane wrote:
I think the main remaining issue is that we don't have consensus on
the function name AFAICT. I'm okay with using width_bucket(), as
is done in the latest patch, but there were objections ...
Just reread tha
Noah Misch writes:
> On Sun, Sep 07, 2014 at 01:06:04PM -0400, Tom Lane wrote:
>> This objection could be met by doing a precheck to verify that the table
>> contains at least one live row. That's pretty ugly and personally I'm not
>> sure it's necessary, but I think there's room to argue that it
On Sun, Sep 07, 2014 at 01:06:04PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Sep 06, 2014 at 02:01:32AM +0200, Marko Tiikkaja wrote:
> >> To do this optimization we do have to assume that CHECKs in
> >> DOMAINs are at least STABLE, but I don't see that as a problem;
> >> those should
On 2014-09-07 15:05:35 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Tom, are you planning to take this one?
>
> Yeah, I already looked at it once, so will take it.
Cool.
> I think the main remaining issue is that we don't have consensus on
> the function name AFAICT. I'm okay with using
Andres Freund writes:
> Tom, are you planning to take this one?
Yeah, I already looked at it once, so will take it.
I think the main remaining issue is that we don't have consensus on
the function name AFAICT. I'm okay with using width_bucket(), as
is done in the latest patch, but there were ob
On 2014-09-07 20:45:38 +0200, Pavel Stehule wrote:
> 2014-09-07 14:29 GMT+02:00 Petr Jelinek :
> > Ah yeah I forgot about those, fixed in attached patch.
> ok
>
> It is ready for commit
Tom, are you planning to take this one?
Greetings,
Andres Freund
--
Andres Freund htt
2014-09-07 14:29 GMT+02:00 Petr Jelinek :
> On 04/09/14 21:16, Pavel Stehule wrote:
>
>>
>> I did a review of last patch
>>
>
> Thanks
>
>
>> I found only one issue - float8 path has no own test in regress tests.
>> When this issue will be fixed, I will mark this patch as ready for commit
>>
>>
>
On 7.9.2014 18:52, Andrew Gierth wrote:
>> "Tomas" == Tomas Vondra writes:
>
> Tomas> Maybe preventing this completely (i.e. raising an ERROR with
> Tomas> "duplicate columns in CUBE/ROLLUP/... clauses") would be
> Tomas> appropriate. Does the standard says anything about this?
>
> The spe
Noah Misch writes:
> I ran libedit-history-fixes-v3.patch through my previous libedit-28 test.
> Now, patched psql writes ^A for newlines in any command. Here's the new
> matrix of behaviors when recalling history:
> master using master-written history:
> oldest command: ok
> rest: ok
On 2014-09-07 19:28, Jeff Janes wrote:
On Wed, Sep 3, 2014 at 2:13 PM, Marko Tiikkaja wrote:
To sign without encrypting?
To verify signatures of things that are not encrypted. I'm not really
interested in storing private keys in PostgreSQL, just things that can be
done with public keys. (B
On Wed, Sep 3, 2014 at 2:13 PM, Marko Tiikkaja wrote:
> On 2014-09-03 10:33 PM, Jeff Janes wrote:
>
>> On Wed, Sep 3, 2014 at 12:43 PM, Marko Tiikkaja wrote:
>>
>>> Right. This patch only adds support for signing data when encrypting it
>>> at the same time. There's no support for detached sig
Noah Misch writes:
> On Sat, Sep 06, 2014 at 02:01:32AM +0200, Marko Tiikkaja wrote:
>> To do this optimization we do have to assume that CHECKs in
>> DOMAINs are at least STABLE, but I don't see that as a problem;
>> those should be IMMUTABLE anyway, I think.
> The system has such assumptions al
> "Tomas" == Tomas Vondra writes:
>> As for computing it all twice, there's currently no attempt to
>> optimize multiple identical grouping sets into multiple
>> projections of a single grouping set result. CUBE(a,b,c,a) has
>> twice as many grouping sets as CUBE(a,b,c) does, even though
> > > I updated the patch to cover semi and anti joins with eqjoinsel_semi().
> > > I think it is better than returning a constant.
> >
> > What you did there is utterly unacceptable from a modularity standpoint;
> > and considering that the values will be nowhere near right, the argument
> > that
On 2014-09-06 9:47 PM, Pavel Stehule wrote:
-1 .. to proposal .. It is in contradiction with current feature.
Which feature would that be?
Next it
is nonsense. INTO clause should to contains only plpgsql variables - in 9.x
Postgres there is not possible issue.
postgres=# create table x(a int,
On 7.9.2014 15:11, Andrew Gierth wrote:
>> "Tomas" == Tomas Vondra writes:
>
> >> It's not one sort per grouping set, it's the minimal number of
> >> sorts needed to express the result as a union of ROLLUP
> >> clauses. The planner code will (I believe) always find the
> >> smallest numbe
On 09/07/2014 02:24 AM, Tom Lane wrote:
>>> >> The problem here seems to be only related to mistyped parameters. Can
>>> >> we contain the damage to that part only somehow? Or make this optional
>>> >> (defaulting to off, I hope)?
>> > I'd love to make it affect only parameters, actually, for v3
> "Tomas" == Tomas Vondra writes:
>> It's not one sort per grouping set, it's the minimal number of
>> sorts needed to express the result as a union of ROLLUP
>> clauses. The planner code will (I believe) always find the
>> smallest number of sorts needed.
Tomas> You're probably right.
On 6.9.2014 23:34, Andrew Gierth wrote:
>> "Tomas" == Tomas Vondra writes:
>
> Tomas> I have significant doubts about the whole design,
> Tomas> though. Especially the decision not to use HashAggregate,
>
> There is no "decision not to use HashAggregate". There is simply no
> support for H
On 04/09/14 21:16, Pavel Stehule wrote:
I did a review of last patch
Thanks
I found only one issue - float8 path has no own test in regress tests.
When this issue will be fixed, I will mark this patch as ready for commit
Ah yeah I forgot about those, fixed in attached patch.
--
Petr Je
Fujii,
* Fujii Masao (masao.fu...@gmail.com) wrote:
> On Fri, Aug 22, 2014 at 8:14 AM, Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> ALTER TABLE ALL IN TABLESPACE xyz
> >> which AFAICS should work since ALL is already a reserved keyword.
> >
> > Pushed to master
34 matches
Mail list logo
