> From: Ali Akbar [mailto:the.ap...@gmail.com]
> Sent: Freitag, 6. Juni 2014 03:44
> Subject: Re: [HACKERS] "pivot aggregation" with a patched intarray
>
> 2014-06-05 17:18 GMT+07:00 Marc Mamin :
> > I'm thinking about adding a final function to my aggregate that would
> > replace zero values will
On Thu, Jun 5, 2014 at 5:39 PM, Gurjeet Singh wrote:
>
> On Wed, Jun 4, 2014 at 12:54 AM, Amit Kapila
wrote:
> > On Tue, Jun 3, 2014 at 5:43 PM, Gurjeet Singh wrote:
> >>
> >> For sizeable shared_buffers size, the restoration of the shared
> >> buffers can take several seconds.
> >
> > Incase of
On Thu, Jun 5, 2014 at 5:37 PM, Peter Geoghegan wrote:
> Even still, the fact that every
> implementation doesn't meet my standard came as a big surprise to me,
> and so I hope that the problem is limited to Mac OSX. I'm slightly
> concerned that all BSD systems are affected by this issue
I tried
Rod Taylor writes:
> On Thu, Jun 5, 2014 at 10:27 PM, Tom Lane wrote:
>> I'm not entirely convinced that it's worth the extra planning cycles,
>> though. Given the small number of complaints to date, it might not
>> be worth doing this. Thoughts?
> Would this avoid execution of expensive funct
On Thu, Jun 5, 2014 at 10:27 PM, Tom Lane wrote:
> I'm not entirely convinced that it's worth the extra planning cycles,
> though. Given the small number of complaints to date, it might not
> be worth doing this. Thoughts?
>
Would this avoid execution of expensive functions in views when thei
A question in pgsql-general made me reflect about how the planner isn't
smart about unreferenced output columns of subqueries that it's not able
to flatten into the parent query. Here's an example:
regression=# create table t1 (f1 int);
CREATE TABLE
regression=# create table t2 (f2 int primary ke
On Thu, Jun 05, 2014 at 10:57:03AM +0200, Andres Freund wrote:
> On 2014-06-04 20:40:40 -0400, Peter Eisentraut wrote:
> > On Wed, 2014-05-07 at 03:08 +0200, Andres Freund wrote:
> > > > As an additional issue it currently doesn't seem to work in VPATH
> > > > builds. That's imo a must fix.
> > >
2014-06-05 17:18 GMT+07:00 Marc Mamin :
> I'm thinking about adding a final function to my aggregate that would replace
> zero values will nulls,
> hence transforming the intarray into a standard int[], possibly with
> nullbitmap and a lowerbound that can be > 1.
> This will probably degrade the
On Thu, Jun 05, 2014 at 07:44:31PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
> >> A bit more crazy, but how about trying trying to plan joins with a added
> >> one-time qual that checks the size of the deferred trigger queue? The
On Jun 5, 2014, at 5:25 PM, Andrew Dunstan wrote:
> My understanding is that it's meant to be analogous to tsquery.
>
> At first glance, JsonPath doesn't seem to support AND and OR operators, which
> would make it rather less expressive than I gather JSQuery is meant to be.
Yes, but perhaps it
On 06/05/2014 08:08 PM, David E. Wheeler wrote:
Oleg, Teodor, and Hackers:
Love what you’re doing with JSQuery. I’m curious, though, whether you
considered adopting an existing syntax, such as JSONPath.
http://goessner.net/articles/JsonPath/
Might be easier for people to pick up and use.
Oleg, Teodor, and Hackers:
Love what you’re doing with JSQuery. I’m curious, though, whether you
considered adopting an existing syntax, such as JSONPath.
http://goessner.net/articles/JsonPath/
Might be easier for people to pick up and use. Thoughts?
Best,
David
signature.asc
Description:
Noah Misch writes:
> On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
>> A bit more crazy, but how about trying trying to plan joins with a added
>> one-time qual that checks the size of the deferred trigger queue? Then
>> we wouldn't even need special case plans.
> That, too, sound
On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
> On 2014-06-04 20:04:07 -0400, Noah Misch wrote:
> > On Wed, Jun 04, 2014 at 10:14:42AM -0400, Tom Lane wrote:
> > > It's possible that we could apply the optimization only to queries that
> > > have been issued directly by a client, b
On Fri, Jun 6, 2014 at 2:43 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Robert Haas wrote:
>>> For my part, I'd strongly prefer a name based on the term "logical
>>> decoding".
>
>> There is no reason not to use long names, so I think pg_logical_decoding
>> is fine.
>
> +1
Indeed. With such a
I wrote:
> I think what we have to do is use a different dummy value for the node
> label of a pushed-down allTheSame tuple than we do for end-of-string.
> This requires widening the node labels from uint8 to (at least) int16.
> However, I think that's essentially free because pass-by-value node
>
On 05/06/14 19:39, Tom Lane wrote:
> Merlin Moncure writes:
>> On Thu, Jun 5, 2014 at 9:54 AM, Linos wrote:
>>> What I don't understand is why the statistics have this bad information,
>>> all my tests are done on a database just restored and analyzed. Can I do
>>> something to improve the qual
On 05/06/14 19:56, Andres Freund wrote:
On June 5, 2014 7:43:06 PM CEST, Tom Lane wrote:
Alvaro Herrera writes:
Robert Haas wrote:
For my part, I'd strongly prefer a name based on the term "logical
decoding".
There is no reason not to use long names, so I think
pg_logical_decoding
is fi
On Fri, May 30, 2014 at 8:08 AM, Heikki Linnakangas wrote:
> On 05/29/2014 07:39 PM, Jeff Janes wrote:
>
>> It also implicitly tested the xlog parallel write slots thing, as that is
>> common code to all recovery.
>>
>
> During development, I hit a lot of bugs in that patch by setting
> wal_buffe
On June 5, 2014 7:43:06 PM CEST, Tom Lane wrote:
>Alvaro Herrera writes:
>> Robert Haas wrote:
>>> For my part, I'd strongly prefer a name based on the term "logical
>>> decoding".
>
>> There is no reason not to use long names, so I think
>pg_logical_decoding
>> is fine.
>
>+1
Still not a fan of
Alvaro Herrera writes:
> Robert Haas wrote:
>> For my part, I'd strongly prefer a name based on the term "logical
>> decoding".
> There is no reason not to use long names, so I think pg_logical_decoding
> is fine.
+1
regards, tom lane
--
Sent via pgsql-hackers mailing
Merlin Moncure writes:
> On Thu, Jun 5, 2014 at 9:54 AM, Linos wrote:
>> What I don't understand is why the statistics have this bad information, all
>> my tests are done on a database just restored and analyzed. Can I do
>> something to improve the quality of my database statistics and let the
On Wed, Jun 4, 2014 at 5:10 PM, Andres Freund
wrote:
> Looks like you're hitting the issue described in
>
> http://archives.postgresql.org/message-id/20140530121631.GE25431%40alap3.anarazel.de
Aha, so the problem looks like this:
- all multixact contents was purged (9.2 to 9.3 incompatibility)
Robert Haas wrote:
> > BTW, the stuff that we have in pg_llog are not really logs at all, so
> > pg_llog was always a misnomer.
>
> Also true.
>
> For my part, I'd strongly prefer a name based on the term "logical
> decoding". This feature has lots of names (change-set extraction,
> logical rep
On Thu, Jun 5, 2014 at 3:54 PM, Linos wrote:
> What I don't understand is why the statistics have this bad information, all
> my tests are done on a database just restored and analyzed. Can I do
> something to improve the quality of my database statistics and let the
> planner do better choices
On Thu, Jun 5, 2014 at 7:12 AM, Heikki Linnakangas
wrote:
>>> BTW, what about also renaming pg_llog directory? I'm afraid that
>>> a user can confuse pg_log with pg_llog.
>>
>> We have:
>> * pg_ldecoding (Heikki)
>> * pg_lcse or pg_lcset (Petr)
>> * pg_logical (Andres)
>>
>> I like, what a surpris
On Thu, Jun 5, 2014 at 9:54 AM, Linos wrote:
> What I don't understand is why the statistics have this bad information, all
> my tests are done on a database just restored and analyzed. Can I do
> something to improve the quality of my database statistics and let the
> planner do better choices
On 05/06/14 16:40, Merlin Moncure wrote:
> On Thu, Jun 5, 2014 at 6:32 AM, Linos wrote:
>> Hello all,
>>
>> This is a continuation of the thread found here:
>> http://www.postgresql.org/message-id/538f2578.9080...@linos.es
>>
>> Considering this seems to be a problem with the planner I thought tha
On 05/06/14 16:40, Merlin Moncure wrote:
> On Thu, Jun 5, 2014 at 6:32 AM, Linos wrote:
>> Hello all,
>>
>> This is a continuation of the thread found here:
>> http://www.postgresql.org/message-id/538f2578.9080...@linos.es
>>
>> Considering this seems to be a problem with the planner I thought tha
On Thu, Jun 5, 2014 at 6:32 AM, Linos wrote:
> Hello all,
>
> This is a continuation of the thread found here:
> http://www.postgresql.org/message-id/538f2578.9080...@linos.es
>
> Considering this seems to be a problem with the planner I thought that maybe
> would be a better idea to post this pr
On 06/04/2014 12:45 AM, Jeff Janes wrote:
On Sun, May 25, 2014 at 8:40 AM, Heikki Linnakangas
wrote:
While debugging the B-tree bug that Jeff Janes reported (
http://www.postgresql.org/message-id/CAMkU=1y=VwF07Ay+Cpqk_
7fpihrctmssv9y99sbghitkxpb...@mail.gmail.com), a new issue came up:
If yo
On 05/06/14 13:32, Linos wrote:
> Hello all,
>
> This is a continuation of the thread found here:
> http://www.postgresql.org/message-id/538f2578.9080...@linos.es
>
> Considering this seems to be a problem with the planner I thought that maybe
> would be a better idea to post this problem here.
>
On Wed, Jun 4, 2014 at 2:50 PM, Robert Haas wrote:
> The thing I was concerned about is that the system might have been in
> recovery for months. What was hot at the time the base backup was
> taken seems like a poor guide to what will be hot at the time of
> promotion. Consider a history table,
On Wed, Jun 4, 2014 at 2:52 PM, Andres Freund wrote:
> On 2014-06-04 14:50:39 -0400, Robert Haas wrote:
>> The thing I was concerned about is that the system might have been in
>> recovery for months. What was hot at the time the base backup was
>> taken seems like a poor guide to what will be ho
On Wed, Jun 4, 2014 at 12:54 AM, Amit Kapila wrote:
> On Tue, Jun 3, 2014 at 5:43 PM, Gurjeet Singh wrote:
>>
>> For sizeable shared_buffers size, the restoration of the shared
>> buffers can take several seconds.
>
> Incase of recovery, the shared buffers saved by this utility are
> from previou
On 2014-06-05 12:57:57 +0200, Andres Freund wrote:
> On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
> > I like using "slot_name" everywhere, i.e, even in recovery.conf.
> > primary_slot_name seems not so long name.
>
> It also has the advantage that we can add a couple more slot_* options
> late
Hello all,
This is a continuation of the thread found here:
http://www.postgresql.org/message-id/538f2578.9080...@linos.es
Considering this seems to be a problem with the planner I thought that maybe
would be a better idea to post this problem here.
To summarize the original thread I upgraded a
On 2014-06-05 14:12:31 +0300, Heikki Linnakangas wrote:
> On 06/05/2014 01:57 PM, Andres Freund wrote:
> >On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
> >We have:
> >* pg_ldecoding (Heikki)
> >* pg_lcse or pg_lcset (Petr)
> >* pg_logical (Andres)
> >
> >I like, what a surprise, my own suggestio
On 06/05/2014 02:10 PM, Magnus Hagander wrote:
On Thu, Jun 5, 2014 at 12:57 PM, Andres Freund
wrote:
We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)
I like, what a surprise, my own suggestion best. The name seems more
versatile because it's not restricted t
On 06/05/2014 01:57 PM, Andres Freund wrote:
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund wrote:
Hi,
Due to the opened window of the pg_control/catalog version bump a chance
has opened to fix a inconsistency I've recently been pointed
towards:
On Thu, Jun 5, 2014 at 12:57 PM, Andres Freund
wrote:
> On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
> > On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund
> wrote:
> > > Hi,
> > >
> > > Due to the opened window of the pg_control/catalog version bump a
> chance
> > > has opened to fix a inconsist
On 2014-06-05 20:02:38 +0900, Michael Paquier wrote:
> On Thu, Jun 5, 2014 at 7:57 PM, Andres Freund wrote:
> > We have:
> > * pg_ldecoding (Heikki)
> > * pg_lcse or pg_lcset (Petr)
> > * pg_logical (Andres)
> pg_decoding, simply?
I don't like it much, because it's pretty much restricted for data
On Thu, Jun 5, 2014 at 7:57 PM, Andres Freund wrote:
> We have:
> * pg_ldecoding (Heikki)
> * pg_lcse or pg_lcset (Petr)
> * pg_logical (Andres)
pg_decoding, simply?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
> On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund wrote:
> > Hi,
> >
> > Due to the opened window of the pg_control/catalog version bump a chance
> > has opened to fix a inconsistency I've recently been pointed
> > towards:
> > Namely that replication
> -Original Message-
> From: Ali Akbar [mailto:the.ap...@gmail.com]
> Sent: Donnerstag, 5. Juni 2014 01:12
> To: Marc Mamin
> Cc: Michael Paquier; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] "pivot aggregation" with a patched intarray
>
> 2014-06-01 20:48 GMT+07:00 Marc Mamin :
> -Original Message-
> Hi,
>
> On 2014-06-05 17:09:44 +0900, furu...@pm.nttdata.co.jp wrote:
> > Synchronous(synchronous_commit = on) mode offers the ability to
> confirm WAL have been streamed in the same way as synchronous
> replication.
> > If an output is used as a different disk from
On 05/06/2014 07:36 PM, Andres Freund wrote:
On 2014-05-06 13:33:01 +0300, Heikki Linnakangas wrote:
On 03/31/2014 09:08 PM, Robert Haas wrote:
On Wed, Mar 26, 2014 at 9:45 PM, Peter Geoghegan wrote:
On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch wrote:
The threat is that rounding the read siz
On Thu, Jun 5, 2014 at 5:37 PM, Andres Freund wrote:
> On 2014-06-05 16:56:08 +0900, Amit Langote wrote:
>> On Thu, Jun 5, 2014 at 4:09 PM, Fujii Masao wrote:
>> > Do we need to back-patch this to older versions (i,e. 9.2, 9.1, ..)?
>> >
>>
>> Yes, this should be backpatched to 9.2, 9.1, 9.0, too
On Thu, Jun 5, 2014 at 5:27 PM, Magnus Hagander wrote:
>
> On Jun 5, 2014 10:22 AM, "Devrim Gündüz" wrote:
>>
>>
>> Hi,
>>
>> On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote:
>> > BTW, what about also renaming pg_llog directory? I'm afraid that
>> > a user can confuse pg_log with pg_llog.
>>
On 2014-06-04 20:40:40 -0400, Peter Eisentraut wrote:
> On Wed, 2014-05-07 at 03:08 +0200, Andres Freund wrote:
> > > As an additional issue it currently doesn't seem to work in VPATH
> > > builds. That's imo a must fix.
> >
> > A "cd $(srcdir) && .." in prove_installcheck and prove_check seems to
Hi,
On 2014-06-05 17:09:44 +0900, furu...@pm.nttdata.co.jp wrote:
> Synchronous(synchronous_commit = on) mode offers the ability to confirm WAL
> have been streamed in the same way as synchronous replication.
> If an output is used as a different disk from the directory where the
> transaction l
On 2014-06-05 16:56:08 +0900, Amit Langote wrote:
> On Thu, Jun 5, 2014 at 4:09 PM, Fujii Masao wrote:
> > Do we need to back-patch this to older versions (i,e. 9.2, 9.1, ..)?
> >
>
> Yes, this should be backpatched to 9.2, 9.1, 9.0, too.
I don't think it really needs to go to 9.0 - that didn't
On Jun 5, 2014 10:22 AM, "Devrim Gündüz" wrote:
>
>
> Hi,
>
> On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote:
> > BTW, what about also renaming pg_llog directory? I'm afraid that
> > a user can confuse pg_log with pg_llog.
>
> +1. I hit this while testing 9.4 this week. Should be confusing f
Hi,
On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote:
> BTW, what about also renaming pg_llog directory? I'm afraid that
> a user can confuse pg_log with pg_llog.
+1. I hit this while testing 9.4 this week. Should be confusing for many
end-users.
Regards,
--
Devrim GÜNDÜZ
Principal Systems
On 05/06/14 10:11, Heikki Linnakangas wrote:
On 06/05/2014 05:09 AM, Amit Langote wrote:
Hi,
On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao
wrote:
I like using "slot_name" everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.
+1
BTW, what about also renaming pg_
Hi,
This patch implements a pg_receivexlog add synchronous mode.
Now, synchronous(synchronous_commit = remote_write) is supported.
But synchronous(synchronous_commit = remote_write), if the server crashes then
WAL file may not to be flushed to disk , causing data loss.
Synchronous(synchronous_
On 06/05/2014 05:09 AM, Amit Langote wrote:
Hi,
On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao wrote:
I like using "slot_name" everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg
On Thu, Jun 5, 2014 at 4:09 PM, Fujii Masao wrote:
> On Thu, Jun 5, 2014 at 3:11 PM, Amit Langote wrote:
>> On Wed, Jun 4, 2014 at 11:10 PM, Fujii Masao wrote:
>>> On Wed, Jun 4, 2014 at 3:26 PM, Amit Langote
>>> wrote:
Hi,
Following (commit 2985e16) has not been backpatched, I
On Thu, Jun 5, 2014 at 3:11 PM, Amit Langote wrote:
> On Wed, Jun 4, 2014 at 11:10 PM, Fujii Masao wrote:
>> On Wed, Jun 4, 2014 at 3:26 PM, Amit Langote wrote:
>>> Hi,
>>>
>>> Following (commit 2985e16) has not been backpatched, I guess.
>>>
>>> ANALYZE hs1;
>>> -ERROR: cannot execute VACUUM
59 matches
Mail list logo
