On Tue, Dec 08, 2020 at 05:29:11PM -0800, Andres Freund wrote:
> I suspect this is related to the pg_upgrade test and the main regression
> test running at the same time. We have the following in
> src/test/regress/GNUMakefile.
Yes, this one is not completely new to -hackers. See patch 0002 here
Hi hackers!
A year ago Vladimir Leskov proposed patch to speed up pglz compression[0]. PFA
the patch with some editorialisation by me.
I saw some reports of bottlenecking in pglz WAL compression [1].
Hopefully soon we will have compression codecs developed by compression
specialists. The work
On Tue, Dec 08, 2020 at 01:28:39PM -0500, Tom Lane wrote:
> Matthias van de Meent writes:
>> On Mon, 7 Dec 2020 at 11:09, Peter Eisentraut
>> wrote:
>>> get_constraint_index() does its work by going through pg_depend. It was
>>> added before pg_constraint.conindid was added, and some callers
On Wed, Dec 09, 2020 at 02:00:44AM +0900, Fujii Masao wrote:
> I agree it might be helpful to display something like
> "checkpointing" or "waiting for checkpoint" in PS title for the
> startup process.
Thanks.
> But, at least for me, it seems strange to display "idle" only for
> checkpointer.
On Sun, 6 Dec 2020 at 04:10, Andy Fan wrote:
> For anyone who is interested with these patchsets, here is my plan about this
> now. 1). I will try EquivalenceClass rather than Expr in UniqueKey and add
> opfamily
> if needed.
I agree that we should be storing them in EquivalenceClasses. Apart
On Mon, Dec 07, 2020 at 02:15:58PM +0100, Daniel Gustafsson wrote:
> This is a pretty straightforward patch which given the cryptohash framework
> added previously does what it says on the tin. +1 on rolling MD5 into what we
> already have for SHA2 now. Applies clean and all tests pass.
Thanks.
On Tue, Dec 8, 2020 at 6:24 PM Hou, Zhijie wrote:
>
> > > I'm not quite sure how to address this. Can we not allow the planner
> > > to consider that the select is for CTAS and check only after the
> > > planning is done for the Gather node and other checks?
> > >
> >
> > IIUC, you are saying
On Tue, Dec 08, 2020 at 02:25:43PM -0400, John Naylor wrote:
> Thanks for taking a look. Sounds good, I've made those adjustments and
> wrote a commit message. I took another look and didn't see anything else to
> address.
Looks good to me, so applied.
--
Michael
signature.asc
Description: PGP
From: Alvaro Herrera
> But what happens when you create another partition after you change the
> "loggedness" of the partitioned table?
The new partition will have a property specified when the user creates it.
That is, while the storage property of each storage unit (=partition) is
basically
Hi!
I created a patch for improving CLOSE, FETCH, MOVE tab completion.
Specifically, I add CLOSE, FETCH, MOVE tab completion for completing a
predefined cursors.
Regards,
Shinya Kato
fix_tab_complete_close_fetch_move.patch
Description: fix_tab_complete_close_fetch_move.patch
On 2020-12-08 22:02:24 -0500, Tom Lane wrote:
> BTW, I observe that with MAXDIM gone from execExpr.h, there are
> no widely-visible uses of MAXDIM except for array.h. I therefore
> suggest that we should pull "#define MAXDIM" out of c.h and put it
> into array.h, as attached. I was slightly
BTW, I observe that with MAXDIM gone from execExpr.h, there are
no widely-visible uses of MAXDIM except for array.h. I therefore
suggest that we should pull "#define MAXDIM" out of c.h and put it
into array.h, as attached. I was slightly surprised to find that
this seems to entail *no* new
On 2020-Dec-08, tsunakawa.ta...@fujitsu.com wrote:
> From: Alvaro Herrera
> > Does "ALTER TABLE ONLY parent" work correctly? Namely, do not affect
> > existing partitions, but cause future partitions to acquire the new
> > setting.
>
> Yes, it works correctly in the sense that ALTER TABLE ONLY
Hi
Since ba3e76c,
the optimizer call generate_useful_gather_paths instead of
generate_gather_paths() outside.
But I noticed that some comment still talking about generate_gather_paths not
generate_useful_gather_paths.
I think we should fix these comment, and I try to replace these "
On Wednesday, December 9, 2020 10:58 AM, Tsunakawa, Takayuki wrote:
> From: Kyotaro Horiguchi
> > At Tue, 8 Dec 2020 16:28:41 +0530, Amit Kapila
> > wrote in
> > I also can't think of a way to use an optimized path for such cases
> > > but I don't agree with your comment on if it is common
From: Kyotaro Horiguchi
> At Tue, 8 Dec 2020 16:28:41 +0530, Amit Kapila
> wrote in
> I also can't think of a way to use an optimized path for such cases
> > but I don't agree with your comment on if it is common enough that we
> > leave this optimization entirely for the truncate path.
>
> An
Andres Freund writes:
> On 2020-12-08 11:05:05 -0500, Tom Lane wrote:
>> Other than that nit, please finish this up and push it so I can finish
>> the generic-subscripting patch.
> Done.
Cool, thanks. I'll fix that part of the generic-subscript patch
and push it tomorrow, unless somebody
On Tue, 8 Dec 2020 at 17:54, Andrey Borodin wrote:
> > In pglogical3 we already support streaming decoded WAL data to
> alternative writer downstreams including RabbitMQ and Kafka via writer
> plugins.
> Yes, Yandex.Cloud Transfer Manger supports it too. But it has to be
> resynced after
Hi,
On 2020-12-08 11:05:05 -0500, Tom Lane wrote:
> I've now studied this patch and it seems sane to me, although
> I wondered why you wrote "extern"s here:
Brainfart...
> Other than that nit, please finish this up and push it so I can finish
> the generic-subscripting patch.
Done.
> > WRT
On Tue, 8 Dec 2020 at 15:04, Andres Freund wrote:
> Hi,
>
> On 2020-12-08 04:24:44 +, tsunakawa.ta...@fujitsu.com wrote:
> > I'm looking forward to this from the async+direct I/O, since the
> > throughput of some write-heavy workload decreased by half or more
> > during checkpointing (due to
Hi,
For fairly obvious reasons I like to run check-world in parallel [1]. In
the last few months I've occasionally seen failures during that that I
cannot recall seeing before.
---
/home/andres/build/postgres/13-assert/vpath/src/test/regress/expected/tablespace.out
2020-12-07
At Tue, 8 Dec 2020 16:28:41 +0530, Amit Kapila wrote
in
> On Tue, Dec 8, 2020 at 12:13 PM tsunakawa.ta...@fujitsu.com
> wrote:
> >
> > From: Jamison, Kirk/ジャミソン カーク
> > > Because one of the rel's cached value was false, it forced the
> > > full-scan path for TRUNCATE.
> > > Is there a
On Wed, Dec 9, 2020 at 12:01 AM Fujii Masao wrote:
>
>
>
> On 2020/12/04 12:21, Kasahara Tatsuhito wrote:
> > Hi,
> >
> > On Thu, Dec 3, 2020 at 9:09 PM Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2020/12/03 11:46, Kasahara Tatsuhito wrote:
> >>> On Wed, Dec 2, 2020 at 7:11 PM Masahiko Sawada
Andres Freund writes:
> On 2020-12-07 17:25:41 -0500, Tom Lane wrote:
>> I can see that that should work for the two existing implementations
>> of EEO_CASE, but I wasn't sure if you wanted to wire in an assumption
>> that it'll always work.
> I don't think it's likely to be a problem, and if it
On Fri, Dec 4, 2020 at 1:29 AM Peter Eisentraut
wrote:
> On 2020-12-02 23:13, Thomas Munro wrote:
> > I'm experimenting with Github's built in CI. All other ideas welcome.
>
> You can run Linux builds on AppVeyor, too.
Yeah. This would be the easiest change to make, because I already
have
Matthias van de Meent writes:
> On Mon, 7 Dec 2020 at 11:09, Peter Eisentraut
> wrote:
>> get_constraint_index() does its work by going through pg_depend. It was
>> added before pg_constraint.conindid was added, and some callers are
>> still not changed. Are there reasons for that? Probably
On Tue, Dec 8, 2020 at 5:45 AM Michael Paquier wrote:
>
> On Mon, Dec 07, 2020 at 03:24:56PM -0400, John Naylor wrote:
> > We've had get_canonical_class() for a while as a backend-only function.
> > There is some ad-hoc code elsewhere that implements the same logic in a
> > couple places, so it
Hi Gilles!
Many thanks for your message!
> 8 дек. 2020 г., в 21:05, Gilles Darold написал(а):
>
> I know that this report is not really helpful
Quite contrary - this benchmarks prove that controllable reproduction exists.
I've rebased patches for PG11. Can you please benchmark them (without
On Tue, Dec 8, 2020 at 6:42 PM Tom Lane wrote:
> "Bossart, Nathan" writes:
> > On 12/7/20, 9:53 AM, "Stephen Frost" wrote:
> >> Concretely, attached is a patch which changes the default and updates
> >> the documentation accordingly.
>
> > +1 to setting checkpoint_completion_target to 0.9 by
"Bossart, Nathan" writes:
> On 12/7/20, 9:53 AM, "Stephen Frost" wrote:
>> Concretely, attached is a patch which changes the default and updates
>> the documentation accordingly.
> +1 to setting checkpoint_completion_target to 0.9 by default.
FWIW, I kind of like the idea of getting rid of it
On 12/7/20, 9:53 AM, "Stephen Frost" wrote:
> Concretely, attached is a patch which changes the default and updates
> the documentation accordingly.
+1 to setting checkpoint_completion_target to 0.9 by default.
Nathan
On 2020/12/05 2:17, Bossart, Nathan wrote:
On 12/3/20, 1:19 PM, "Bossart, Nathan" wrote:
I like the idea behind this patch. I wrote a new version with a
couple of changes:
I missed an #include in this patch. Here's a new one with that fixed.
I agree it might be helpful to display
On 6/15/20 11:49 AM, Peter Eisentraut wrote:
> To fix the star expansion I had to add a little bit of infrastructure
> that could also be used as a more general facility "don't include this
> column in star expansion", so this could perhaps use some consideration
> from a more general angle as
On 5/22/20 12:40 PM, Vik Fearing wrote:
>>> 2)
>>> This query is an infinite loop, as expected:
>>>
>>> with recursive a as (select 1 as b union all select b from a)
>>> table a;
>>>
>>> But it becomes an error when you add a cycle clause to it:
>>>
>>> with recursive a as (select 1 as b
Le 13/11/2020 à 12:49, Andrey Borodin a écrit :
10 нояб. 2020 г., в 23:07, Tomas Vondra
написал(а):
On 11/10/20 7:16 AM, Andrey Borodin wrote:
but this picture was not stable.
Seems we haven't made much progress in reproducing the issue :-( I guess
we'll need to know more about the
Andres Freund writes:
> I've attached a prototype conversion for two other such places. Which
> immediately pointed to a bug. And one harmless issue (using a pointer to
> size_t instead of ExprEvalOp* to represent the 'op' parameter), which
> you promptly copied...
> If I pushed a slightly
On Tue, Dec 8, 2020 at 6:36 PM Bharath Rupireddy
wrote:
>
> On Tue, Dec 8, 2020 at 6:24 PM Hou, Zhijie wrote:
> >
> > > > I'm not quite sure how to address this. Can we not allow the planner
> > > > to consider that the select is for CTAS and check only after the
> > > > planning is done for the
On 2020/12/04 12:21, Kasahara Tatsuhito wrote:
Hi,
On Thu, Dec 3, 2020 at 9:09 PM Fujii Masao wrote:
On 2020/12/03 11:46, Kasahara Tatsuhito wrote:
On Wed, Dec 2, 2020 at 7:11 PM Masahiko Sawada wrote:
On Wed, Dec 2, 2020 at 3:33 PM Fujii Masao wrote:
On 2020/12/02 12:53,
On Mon, 7 Dec 2020 at 11:09, Peter Eisentraut
wrote:
>
> get_constraint_index() does its work by going through pg_depend. It was
> added before pg_constraint.conindid was added, and some callers are
> still not changed. Are there reasons for that? Probably not. The
> attached patch changes
Hi, Robert!
First of all, thanks for your detailed reply.
> On Dec 3, 2020, at 2:23 AM, Robert Haas wrote:
>
> Like, in the protocol that you proposed previously, you've got a
> four-phase handshake to set up compression. The startup packet carries
> initial information from the client, and
On Mon, Dec 7, 2020 at 2:35 PM Greg Nancarrow wrote:
>
> On Fri, Nov 20, 2020 at 7:44 PM Greg Nancarrow wrote:
> >
> > Posting an updated set of patches, with some additional testing and
> > documentation updates, and including the latest version of the
> > Parallel Insert patch.
> > Any
On 11/21/20 10:07 AM, Krasiyan Andreev wrote:
> Fixed patch attached, after new introduced conflicts.
> Vik, can you add it to the next commitfest, to be able to test it.
I have done this now. Thanks!
--
Vik Fearing
On 11/9/20 9:29 AM, Vik Fearing wrote:
> Hello,
>
> I've been doing some benchmarking on recent version of PostgreSQL and
> I'm seeing some regressions. The benchmark setup is as described in [1]
> except it looks like I got lucky in the runs used for that article.
>
> After many more runs, I
I format query to read it more easy. See attachment
Tuesday, December 8, 2020, 3:43:13 PM, you wrote:
Hello Tom,
>>> Also would be useful if PG point at query where this bad value was
>>> calculated or occur.
>> This is not the first time we've seen this request and it usually ends up
>>
Hello Tom,
>>> Also would be useful if PG point at query where this bad value was
>>> calculated or occur.
>> This is not the first time we've seen this request and it usually ends up
>> getting stalled because its non-trivial to implement and thus isn't
>> feasible for the benefit it brings.
>
Andrey, thanks for your feedback!
I agree that AMs with fix sized blocks can have much alike code in
acquire_sample_rows() (though it is not a rule). But there are several points
about current master sampling.
* It is not perfect - AM developers may want to improve it with other sampling
On Tue, Dec 8, 2020 at 6:24 PM Hou, Zhijie wrote:
>
> > > I'm not quite sure how to address this. Can we not allow the planner
> > > to consider that the select is for CTAS and check only after the
> > > planning is done for the Gather node and other checks?
> > >
> >
> > IIUC, you are saying
Hi,
Currently, for any component (such as COPY, CTAS[1], CREATE/REFRESH
Mat View[1], INSERT INTO SELECTs[2]) multi insert logic such as buffer
slots allocation, maintenance, decision to flush and clean up, need to
be implemented outside the table_multi_insert() API. The main problem
is that it
> > I'm not quite sure how to address this. Can we not allow the planner
> > to consider that the select is for CTAS and check only after the
> > planning is done for the Gather node and other checks?
> >
>
> IIUC, you are saying that we should not influence the cost of gather node
> even when
On 2020/12/08 11:55, Craig Ringer wrote:
Hi all
A new kernel API called io_uring has recently come to my attention. I assume
some of you (Andres?) have been following it for a while.
io_uring appears to offer a way to make system calls including reads, writes,
fsync()s, and more in a
On 12/7/20 5:15 PM, Dean Rasheed wrote:
> On Wed, 2 Dec 2020 at 15:51, Dean Rasheed wrote:
>>
>> The sort of queries I had in mind were things like this:
>>
>> WHERE (a = 1 AND b = 1) OR (a = 2 AND b = 2)
>>
>> However, the new code doesn't apply the extended stats directly using
>>
On Mon, Dec 7, 2020 at 7:04 PM Bharath Rupireddy
wrote:
>
> I'm not quite sure how to address this. Can we not allow the planner
> to consider that the select is for CTAS and check only after the
> planning is done for the Gather node and other checks?
>
IIUC, you are saying that we should not
On 12/7/20 5:02 PM, Dean Rasheed wrote:
> On Mon, 7 Dec 2020 at 14:15, Tomas Vondra
> wrote:
>>
>> On 12/7/20 10:56 AM, Dean Rasheed wrote:
>>> it might actually be
>>> neater to have separate documented syntaxes for single- and
>>> multi-column statistics:
>>>
>>> CREATE STATISTICS [ IF
On 2020-12-08 16:45, Li Japin wrote:
Hi,
On Dec 8, 2020, at 1:06 PM, Masahiro Ikeda
wrote:
Hi,
I propose to add wal write/fsync statistics to pg_stat_wal view.
It's useful not only for developing/improving source code related to
WAL
but also for users to detect workload changes, HW
On Tue, Dec 8, 2020 at 12:13 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Jamison, Kirk/ジャミソン カーク
> > Because one of the rel's cached value was false, it forced the
> > full-scan path for TRUNCATE.
> > Is there a possible workaround for this?
>
> Hmm, the other two relfilenodes are for the
On Tue, Dec 8, 2020 at 1:26 PM Andrey Borodin wrote:
> > 25 нояб. 2020 г., в 19:10, Alexander Korotkov
> > написал(а):
> >
> > In the code stop events are defined using macro STOPEVENT(event_id,
> > params). The 'params' should be a function call, and it's evaluated only
> > if stop events
Hi Alexander!
> 25 нояб. 2020 г., в 19:10, Alexander Korotkov
> написал(а):
>
> In the code stop events are defined using macro STOPEVENT(event_id, params).
> The 'params' should be a function call, and it's evaluated only if stop
> events are enabled.
Hi,
Based on a PoC reported in a previous thread [1] I'd like to propose new
hooks around transaction commands. The objective of this patch is to
allow PostgreSQL extension to act at start and end (including abort) of
a SQL statement in a transaction.
The idea for these hooks is born from the no
On Tue, Dec 8, 2020 at 11:53 AM Peter Smith wrote:
>
> Yes, I observed this same behavior.
>
> IIUC the only way for the tablesync worker to go from CATCHUP mode to
> SYNCDONE is via the call to process_sync_tables.
>
> But a side-effect of this is, when messages arrive during this CATCHUP
>
On 06.12.2020 23:50, Konstantin Knizhnik wrote:
Hi hackers!
Due to the error in PG-ProEE we have added the following test to
pg_visibility:
create table vacuum_test as select 42 i;
vacuum vacuum_test;
select count(*) > 0 from pg_check_visible('vacuum_test');
drop table vacuum_test;
Thanks Craig!
Probably, I should better ask in your nearby thread about logical replication,
it just seemed to me that logical archiving is somewhat small independent piece
of functionality...
> 7 дек. 2020 г., в 08:05, Craig Ringer
> написал(а):
>
> Reply follows inline. I addressed your
On Mon, Dec 07, 2020 at 03:24:56PM -0400, John Naylor wrote:
> We've had get_canonical_class() for a while as a backend-only function.
> There is some ad-hoc code elsewhere that implements the same logic in a
> couple places, so it makes sense for all sites to use this function
> instead, as in
On Tue, Dec 1, 2020 at 2:15 PM vignesh C wrote:
>
> On Tue, Dec 1, 2020 at 9:31 AM Tom Lane wrote:
> >
> > Andres Freund writes:
> > > It should be quite doable to emit such backtraces directly to stderr,
> > > instead of using appendStringInfoString()/elog().
> >
> > No, please no.
> >
> > (1)
On Mon, Dec 7, 2020 at 11:01 PM Amit Langote wrote:
> On Fri, Dec 4, 2020 at 12:05 PM Kyotaro Horiguchi
> wrote:
> > > Also, the comment that was in RI_ConstraintInfo now appears in
> > > RI_ConstraintParam, and the new struct (RI_ConstraintInfo) is now
> > > undocumented. What is the
On Thu, 3 Dec 2020 at 21:32, Tom Lane wrote:
> Krunal Bauskar writes:
> > Any updates or further inputs on this.
>
> As far as LSE goes: my take is that tampering with the
> compiler/platform's default optimization options requires *very*
> strong evidence, which we have not got and likely
Hi Denis!
> 7 дек. 2020 г., в 18:23, Смирнов Денис написал(а):
>
> I suggest a refactoring of analyze AM API as it is too much heap specific at
> the moment. The problem was inspired by Greenplum’s analyze improvement for
> append-optimized row and column AM with variable size compressed
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
The patch looks good to me. With regards to the code comments, I had
It seems that my mailing client set wrong MIME types for attached patch and it
was filtered by the web archive. So I attach the patch again for the web
archive.
diff --git a/contrib/file_fdw/file_fdw.c b/contrib/file_fdw/file_fdw.c
index 9863e32748..3cdb839489 100644
---
68 matches
Mail list logo
