On Sun, 9 Jun 2019 at 17:11, Justin Pryzby wrote:
> Sorry, but I think this is still an issue:
>
> >Choosing the target number of partitions into which the table should be
> >divided by is also a critical decision to make. Not having enough
>
> I think it should say:
>
> |Choosing the
On Mon, Jun 3, 2019 at 10:56 PM Tom Lane wrote:
>
> Amit Langote writes:
> > On 2019/05/30 18:51, Amit Kapila wrote:
> >> I think it will be better to include postgres_fdw in the comment in
> >> some way so that if someone wants a concrete example, there is
> >> something to refer to.
>
> > Maybe
On Sun, Jun 09, 2019 at 05:07:39PM +1200, David Rowley wrote:
> On Sun, 9 Jun 2019 at 16:21, Justin Pryzby wrote:
> > I meant it should say "into which it should be divided" and not "by which it
> > should be divided INTO", which has too many prepositions. This is still an
> > issue:
>
> It now
On Sun, 9 Jun 2019 at 16:21, Justin Pryzby wrote:
> I meant it should say "into which it should be divided" and not "by which it
> should be divided INTO", which has too many prepositions. This is still an
> issue:
It now reads "divided by" instead of "divided into".
> |these two types of w
On Sun, Jun 09, 2019 at 01:15:09PM +1200, David Rowley wrote:
> Thanks for having another look.
>
> On Sat, 8 Jun 2019 at 18:39, Justin Pryzby wrote:
> > +to keep exists in that partition then that means having to resort to
> > using
> > +DELETE instead of removing the partition.
> > +
On Sat, Jun 08, 2019 at 10:24:39AM +0900, Michael Paquier wrote:
> Indeed, this makes the header more consistent. Thanks for noticing.
Double-checked the surroundings, and done.
--
Michael
signature.asc
Description: PGP signature
On Sat, Jun 08, 2019 at 04:23:55PM +0200, Guillaume Lelarge wrote:
> We might find more typos, but it will take time. Applying this patch now
> (if it fits you) is probably better.
I can imagine that it is a daunting task... Ok, for now I have
applied what you sent. Thanks!
--
Michael
signatur
Thanks for having another look.
On Sat, 8 Jun 2019 at 18:39, Justin Pryzby wrote:
> +
> +The choice of how to partition a table should be made carefully as the
> +performance of query planning and execution can be negatively affected by
> +poorly made design decisions.
>
> Maybe ju
On Sat, 8 Jun 2019 at 20:09, Andres Freund wrote:
> Hi,
>
> On 2019-06-08 19:41:34 -0400, Dave Cramer wrote:
> > So the reason we are discussing using pgoutput plugin is because it is
> part
> > of core and guaranteed to be in cloud providers solutions.
>
> IMO people needing this should then ban
Hi,
On 2019-06-08 19:41:34 -0400, Dave Cramer wrote:
> So the reason we are discussing using pgoutput plugin is because it is part
> of core and guaranteed to be in cloud providers solutions.
IMO people needing this should then band together and write one that's
suitable, rather than trying to co
This should have gone to hackers as well
-- Forwarded message -
From: Dave Cramer
Date: Sat, Jun 8, 2019, 6:41 PM
Subject: Re: Binary support for pgoutput plugin
To: Tomas Vondra
On Sat, Jun 8, 2019, 6:27 PM Tomas Vondra,
wrote:
> On Fri, Jun 07, 2019 at 06:01:12PM -0700, A
On Fri, Jun 07, 2019 at 06:01:12PM -0700, Andres Freund wrote:
Hi,
On 2019-06-07 20:52:38 -0400, Chapman Flack wrote:
It seems they had ended up designing a whole 'nother "protocol level"
involving queries wrapping their results as JSON and an app layer that
unwraps again, after trying a simple
Thanks for these suggestions.
On Fri, 7 Jun 2019 at 19:00, Amit Langote wrote:
> Some rewording suggestions.
>
> 1.
>
> +...Removal of unwanted data is also a factor to consider when
> +planning your partitioning strategy as an entire partition can be removed
> +fairly quickly. H
On Fri, Jun 7, 2019 at 6:02 PM Ian Barwick wrote:
> On 6/7/19 9:00 PM, Michael Paquier wrote:
> > On Fri, Jun 07, 2019 at 03:44:14PM +0900, Masahiko Sawada wrote:
> > Or is that not worth bothering except on HEAD? Thoughts?
>
> Personally I don't think it's that critical, but not bothered either
> On Sat, Jun 8, 2019 at 5:30 PM Andres Freund wrote:
>
> On 2019-06-08 16:03:09 +0200, Dmitry Dolgov wrote:
> > > On Thu, Jun 6, 2019 at 9:06 AM Michael Paquier
> > > wrote:
> > > The table AM lookup happens only when creating a table, so we could just
> > > get
> > > a failure when attempting
Hi,
On 2019-06-08 16:03:09 +0200, Dmitry Dolgov wrote:
> > On Thu, Jun 6, 2019 at 9:06 AM Michael Paquier wrote:
> > The table AM lookup happens only when creating a table, so we could just get
> > a failure when attempting to create a table with this incorrect value.
>
> is correct, but doesn't
Hi,
On 2019-06-06 16:06:36 +0900, Michael Paquier wrote:
> On Thu, Jun 06, 2019 at 11:19:48AM +1000, Haribabu Kommi wrote:
> > Thanks for the details steps to reproduce the bug, I am also able to
> > reproduce the problem.
>
> This way is even more simple, no need for zheap to be around:
> =# cre
Le sam. 8 juin 2019 à 15:44, Julien Rouhaud a écrit :
> On Sat, Jun 8, 2019 at 3:33 PM Michael Paquier
> wrote:
> >
> > Hi Guillaume,
> >
> > On Wed, May 29, 2019 at 08:28:59PM +0200, Guillaume Lelarge wrote:
> > > Sure.
> >
> > I have noticed your message on the French list about the completion
Hi,
While fixing the breakage caused by the default number of trailing
digits output for real and double precision, I noticed that first
random() call after setseed(0) doesn't return the same value as 10 and
earlier (I tested 9.4 and later). It changed an expected behavior and
it should be listed
> On Thu, Jun 6, 2019 at 9:06 AM Michael Paquier wrote:
>
> I was wondering if we actually need at all a catalog lookup at this
> stage, simplifying get_table_am_oid() on the way so as we always
> throw an error (its missing_ok is here to allow a proper error in the
> GUC context).
Just for me to
On Sat, Jun 8, 2019 at 3:33 PM Michael Paquier wrote:
>
> Hi Guillaume,
>
> On Wed, May 29, 2019 at 08:28:59PM +0200, Guillaume Lelarge wrote:
> > Sure.
>
> I have noticed your message on the French list about the completion of
> the traduction, and congrats for that, it is a huge amount of work.
Hi Guillaume,
On Wed, May 29, 2019 at 08:28:59PM +0200, Guillaume Lelarge wrote:
> Sure.
I have noticed your message on the French list about the completion of
the traduction, and congrats for that, it is a huge amount of work.
Did you find anything else after your last report?
--
Michael
signa
I like the approach proposed by Andres: A more aggressive approach
would be to teach vac_update_datfrozenxid() to ignore orphaned temp
tables... In fact, I suppose all temporary tables and their content
could be completly ignored by MVCC principles as they are not subject
to concurrency bei
Round pegs fit into square holes when the peg is smaller.,..
Hey why did the chicken follow Simon off the ledge?
Just because he told him to?!! Was he really trying to get home, did he
find out the hard way things no one else knows but what he had learnt on
the other side, just to let you know
24 matches
Mail list logo
