On Mon, May 19, 2014 at 5:47 PM, Dilip kumar wrote:
> On 18 May 2014 16:38 David Rowley Wrote
>
>
>
> Sound like a good idea to me..
>
>
>
> I have one doubt regarding the implementation, consider the below query
>
>
>
> Create table t1 (a int, b int);
>
> Create table t2 (a int, b int);
>
>
>
>
On 18 May 2014 16:38 David Rowley Wrote
Sound like a good idea to me..
I have one doubt regarding the implementation, consider the below query
Create table t1 (a int, b int);
Create table t2 (a int, b int);
Create unique index on t2(b);
select x.a from t1 x left join (select distinct t2.a a1,
On Sun, May 18, 2014 at 04:08:41PM -0400, Andrew Dunstan wrote:
>
> On 05/05/2014 07:26 PM, Andrew Dunstan wrote:
> >
> >On 05/05/2014 07:16 PM, Bruce Momjian wrote:
> >>Current text is:
> >>
> >>Add structured (non-text) data type (JSONB) for storing JSON
> >>data (Oleg
> >>Bartunov, Teod
On Thu, May 15, 2014 at 06:08:47PM -0700, David G Johnston wrote:
> Some errors and suggestions - my apologizes for the format as I do not have
> a proper patching routine setup.
>
> Patch Review - Top to Bottom (mostly, I think...)
I have made your suggested adjustments in the attached applied p
On Fri, May 16, 2014 at 02:10:40AM +0200, Andres Freund wrote:
> I am not really sure how to rewrite the notes for the logical decoding
> stuff into a more appropriate format for the release notes. Currently it
> seems to describe too many details and not enough overview. It's also
> probably too l
On Fri, May 16, 2014 at 02:10:40AM +0200, Andres Freund wrote:
> On 2014-05-04 08:46:07 -0400, Bruce Momjian wrote:
> > I have completed the initial version of the 9.4 release notes. You can
> > view them here:
> >
> > http://www.postgresql.org/docs/devel/static/release-9-4.html
> >
> > I wi
On 18-05-2014 05:40, Raghavendra wrote:
> Hi,
>
> PostgreSQL 9.4 document for pg_stat_replication view mentions column name
> as "backend_xid", whereas when a view described it shows column name as
> "backend_xmin".
> http://www.postgresql.org/docs/devel/static/monitoring-stats.html#PG-STAT-REPLIC
On Fri, May 16, 2014 at 2:03 AM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> Hi all,
>
> Are there some reason to don't show the tablespace size in the \db+ psql
command?
>
The attached patch show tablespace size in \db+ psql command.
Regards,
--
Fabrízio de Royes Mello
Consult
Hi,
Here are some more trivial fixes in pg_recvlogical message style.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>From 0bbf437b490a92afa4b14e4903188bcf795f8e47 Mon Sep 17 00:00:00 2001
From:
On 2014-05-18 17:56:48 -0400, Tom Lane wrote:
> The bad news is that the kernel guys have been ignoring the issue
> for over a year. Dunno if some pressure from the Debian camp would
> help raise their priority for this.
I guess we should forward the bug to the lkml/linux-mm lists. I think a
fair
On 2014-05-18 23:52:32 +0200, Andres Freund wrote:
> On 2014-05-18 17:41:17 -0400, Tom Lane wrote:
> > Christoph Berg writes:
> > > Re: Andres Freund 2014-05-18 <20140518091445.gu23...@alap3.anarazel.de>
> > >> Did you measure how large the stack actually was when you got the
> > >> SIGBUS? Should
Andres Freund writes:
> On 2014-05-18 17:41:17 -0400, Tom Lane wrote:
>> OK, so the problem is that getrlimit(RLIMIT_STACK) is lying to us about
>> the available stack depth. I'd classify that as a kernel bug. I wonder
>> if it's a different manifestation of this issue:
>> https://bugzilla.redha
On 2014-05-18 17:41:17 -0400, Tom Lane wrote:
> Christoph Berg writes:
> > Re: Andres Freund 2014-05-18 <20140518091445.gu23...@alap3.anarazel.de>
> >> Did you measure how large the stack actually was when you got the
> >> SIGBUS? Should be possible to determine that by computing the offset
> >> u
Christoph Berg writes:
> Re: Andres Freund 2014-05-18 <20140518091445.gu23...@alap3.anarazel.de>
>> Did you measure how large the stack actually was when you got the
>> SIGBUS? Should be possible to determine that by computing the offset
>> using some local stack variable in one of the depeest sta
Re: Andres Freund 2014-05-18 <20140518091445.gu23...@alap3.anarazel.de>
> Did you measure how large the stack actually was when you got the
> SIGBUS? Should be possible to determine that by computing the offset
> using some local stack variable in one of the depeest stack frames.
Looking at /proc/
Andres Freund wrote:
> On 2014-05-17 23:35:43 +0200, Christoph Berg wrote:
> > Fwiw, this wasn't the first time I've heard of that idea, it also
> > doesn't sound too far-fetched for me. I guess people usually go "damn,
> > I can't rename active dbs, let's try something else" instead of
> > compla
On 05/05/2014 07:26 PM, Andrew Dunstan wrote:
On 05/05/2014 07:16 PM, Bruce Momjian wrote:
Current text is:
Add structured (non-text) data type (JSONB) for storing JSON data
(Oleg
Bartunov, Teodor Sigaev, Alexander Korotkov, Peter Geoghegan, and
Andrew
Dunstan)
This allows
Andres Freund writes:
> On 2014-05-17 22:55:14 +0200, Tomas Vondra wrote:
>> And another memory context stats for a session executing CREATE INDEX,
>> while having allocated The interesting thing is there are ~11k lines
>> that look exactly like this:
>>
>> pg_namespace_oid_index: 1024 total in
On Sat, May 17, 2014 at 8:57 PM, David Rowley wrote:
> I'm currently in the early stages of looking into expanding join removals.
>
> Currently left outer joins can be removed if none of the columns of the
> table are required for anything and the table being joined is a base table
> that contain
On 2014-05-18 11:08:34 +0200, Christoph Berg wrote:
> > > Interestingly, the Debian buildd managed to run the testsuite for
> > > i386, while I could reproduce the problem on the pgapt build machine
> > > and on my notebook, so there must be some system difference. Possibly
> > > the reason is thes
Re: Tom Lane 2014-05-18 <9058.1400385...@sss.pgh.pa.us>
> Christoph Berg writes:
> > Re: Tom Lane 2014-05-14 <1357.1400028...@sss.pgh.pa.us>
> >> It would appear that something is wrong with check_stack_depth(),
> >> and/or getrlimit(RLIMIT_STACK) is lying to us about the available stack.
>
> > u
Hello
I am looking on --analyze-in-stages option. If I understand well,
motivation for this option is a get some minimal statistic for databases in
minimal time. But when I tested, I found so iterations are per databases,
not per stages - some first database get a maximum statistics and second
has
22 matches
Mail list logo
