On 27/03/2019 22:28, Peter Eisentraut wrote:
> On 2019-03-26 16:28, Euler Taveira wrote:
>> I don't remember why we didn't consider table without stats to be
>> ANALYZEd. Isn't it the case to fix autovacuum? Analyze
>> autovacuum_count + vacuum_count = 0?
>
> When the autovacuum system was introdu
Please don't top post. It makes it unnecessarily difficult to follow the
discussion. See https://wiki.postgresql.org/wiki/Mailing_Lists
On Fri, Apr 12, 2019 at 08:56:35PM +0200, Fred .Flintstone wrote:
So there is no regression potential.
I fail to understand how you came to this conclusion?
On Sat, Apr 13, 2019 at 3:36 PM Tomas Vondra
wrote:
> On Fri, Apr 12, 2019 at 08:56:35PM +0200, Fred .Flintstone wrote:
> >So there is no regression potential.
> >
>
> I fail to understand how you came to this conclusion? Andreas pointed
> out Debian already uses pg_createcluster, so there clearly
Andres Freund writes:
> On 2019-04-12 14:17:11 -0400, Tom Lane wrote:
>> While looking at the pending patch to clean up management of
>> rd_partcheck, I noticed that RelationCacheInitializePhase3 has code that
>> purports to reload rd_partkey and rd_partdesc, but none for rd_partcheck.
>> However,
I wrote:
> Whether it would be nice or not is irrelevant to my point: this code
> doesn't work, and it's unlikely that it would ever be part of a working
> solution. I don't think there's any way that it'd be sane to attempt
> catalog accesses during RelationCacheInitializePhase3.
BTW, to clarify
Thanks for the updated patch.
On Sat, Apr 13, 2019 at 4:47 AM Tom Lane wrote:
> Robert Haas writes:
> > As a parenthetical note, I observe that relcache.c seems to know
> > almost nothing about rd_partcheck. rd_partkey and rd_partdesc both
> > have handling in RelationClearRelation(), but rd_pa
Amit Langote writes:
> On Sat, Apr 13, 2019 at 4:47 AM Tom Lane wrote:
>> I concluded that that's not parenthetical but pretty relevant...
> Hmm, do you mean we should grow the same "keep_" logic for
> rd_partcheck as we have for rd_partkey and rd_partdesc? I don't see
> it in the updated patch
Andreas Karlsson wrote:
> The Debian packagers already use pg_createcluster for their script which
> wraps initdb, and while pg_initdb is a bit misleading (it creates a
> cluster rather than a database) it is not that bad.
But that renaming wouldn't achieve anything in relation to the s
Amit Langote writes:
> To save you the pain of finding the right files to patch in
> back-branches, I made those (attached).
BTW, as far as that goes: I'm of the opinion that the partitioning logic's
factorization in this area is pretty awful, and v12 has made it worse not
better. It's important
I started looking at this the other night but I see Magnus beat me in
committing it...
On Fri, Apr 12, 2019 at 8:18 AM Magnus Hagander wrote:
> On Sun, Apr 7, 2019 at 6:28 PM Julien Rouhaud wrote:
>> Thanks for looking it it!
>> On Sun, Apr 7, 2019 at 4:36 PM Magnus Hagander wrote:
>> >
>> > I'
On Thu, Apr 11, 2019 at 11:25:29AM +0200, Chris Travers wrote:
On Wed, Apr 10, 2019 at 5:21 PM Andres Freund wrote:
Hi,
On April 10, 2019 8:13:06 AM PDT, Alvaro Herrera
wrote:
>On 2019-Mar-31, Darafei "Komяpa" Praliaskouski wrote:
>
>> Alternative point of "if your d
On Thu, Apr 11, 2019 at 02:55:10PM +0500, Ibrar Ahmed wrote:
On Thu, Apr 11, 2019 at 2:44 PM Erikjan Rijkers wrote:
On 2019-04-11 11:36, Ibrar Ahmed wrote:
> Hi,
>
> Is it possible to have commit-message or at least git hash in
> commitfest. It will be very easy to track commit against commitf
Tomas Vondra writes:
> On Thu, Apr 11, 2019 at 02:55:10PM +0500, Ibrar Ahmed wrote:
>> On Thu, Apr 11, 2019 at 2:44 PM Erikjan Rijkers wrote:
Is it possible to have commit-message or at least git hash in
commitfest. It will be very easy to track commit against commitfest
item.
>>>
Hello devs,
The attached patch implements a new SHOW_ALL_RESULTS option for psql,
which shows all results of a combined query (\;) instead of only the last
one.
This solves a frustration that intermediate results were hidden from view
for no good reason that I could think of.
For that, ca
On Wed, Apr 10, 2019 at 08:09:34PM -0300, Euler Taveira wrote:
Em qua, 10 de abr de 2019 às 16:33, Alvaro Herrera
escreveu:
On 2019-Apr-10, Bruce Momjian wrote:
> On Thu, Apr 11, 2019 at 04:14:11AM +1200, David Rowley wrote:
> > I still think we should start with a warning about pg_stat_rese
On 04/13/19 15:56, Tomas Vondra wrote:
> I think it might be useful to actually have that directly in the CF app,
> not just in the thread. There would need to a way to enter multiple
> hashes, because patches often have multiple pieces.
The CF app already recognizes (some) attachments in the emai
On Sat, Apr 13, 2019 at 04:27:56PM -0400, Tom Lane wrote:
> Tomas Vondra writes:
> > On Thu, Apr 11, 2019 at 02:55:10PM +0500, Ibrar Ahmed wrote:
> >> On Thu, Apr 11, 2019 at 2:44 PM Erikjan Rijkers wrote:
> Is it possible to have commit-message or at least git hash in
> commitfest. It
On Thu, Apr 11, 2019 at 6:06 AM Rafia Sabih wrote:
> Reading about it reminds me of this work -- TAG column storage(
> http://www09.sigmod.org/sigmod/record/issues/0703/03.article-graefe.pdf ).
> Isn't this storage system inspired from there, with TID as the TAG?
>
> It is not referenced here so
Hi,
I'm trying to use the SPI to save the executed plans in the ExecutorEnd. When
the plan involves multiple workers, the insert operations would trigger an
error: cannot execute INSERT during a parallel operation.
I wonder if there's a different hook I can use when there's a gather node? or
o
Hi,
Both tables in $subject (in datatype.sgml and xfunc.sgml, respectively)
contain similar information (though the xfunc one mentions C structs and
header files, and the datatype one does not, but has a description column)
and seem similarly out-of-date with respect to the currently supported
typ
20 matches
Mail list logo
