Re: Improvements in Copy From

My basic understanding of first part of your patch is that by adjusting the "minread" it now allows it to loop multiple times internally within the CopyGetData rather than calling CopyLoadRawBuf for every N lines. There doesn't seem to be much change to what other code gets executed so the saving i

Re: Yet another fast GiST build

> 9 сент. 2020 г., в 00:05, Heikki Linnakangas написал(а): > > I've been reviewing the patch today. The biggest changes I've made have been > in restructuring the code in gistbuild.c for readability, but there are a > bunch of smaller changes throughout. Attached is what I've got so far, >

Re: Inconsistent Japanese name order in v13 contributors list

On Tue, Sep 8, 2020 at 10:15 PM Etsuro Fujita wrote: > Attached is a patch to standardize Japanese names as given-name-first > in the v13 contributors list as before. I recently read that the Japanese government issued a decree about this: https://www.economist.com/asia/2020/01/02/why-japanese-n

Re: Improving connection scalability: GetSnapshotData()

On 2020/09/09 2:53, Andres Freund wrote: Hi, On 2020-09-08 16:44:17 +1200, Thomas Munro wrote: On Tue, Sep 8, 2020 at 4:11 PM Andres Freund wrote: At first I was very confused as to why none of the existing tests have found this significant issue. But after thinking about it for a minute that

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Sat, 2020-09-05 at 12:03 -0700, Peter Geoghegan wrote: > The comments in ltsWriteBlock() added by the 2017 bugfix commit > 7ac4a389a7d clearly say that the zero block writing stuff is only > supposed to happen at the edge of a tape boundary, which ought to be > rare -- see the comment block in l

Re: Inconsistent Japanese name order in v13 contributors list

On Wed, Sep 9, 2020 at 2:58 PM tsunakawa.ta...@fujitsu.com wrote: > From: Fujii Masao > > On 2020/09/09 14:15, Etsuro Fujita wrote: > > > Attached is a patch to standardize Japanese names as given-name-first > > > in the v13 contributors list as before. > > > > Using given-name-first order is our

Re: [PATCH] Detect escape of ErrorContextCallback stack pointers (and from PG_TRY() )

On Tue, 8 Sep 2020 at 10:56, Tom Lane wrote: > > So that's good. However, a similar experiment with returning from inside > a PG_TRY does *not* produce a warning. I suspect maybe the compiler > throws up its hands when it sees sigsetjmp? > I find that odd myself, given that in PG_TRY() we:

RE: Inconsistent Japanese name order in v13 contributors list

From: Fujii Masao > On 2020/09/09 14:15, Etsuro Fujita wrote: > > Attached is a patch to standardize Japanese names as given-name-first > > in the v13 contributors list as before. > > Using given-name-first order is our consensus? I was thinking we have not > reached that yet and our "vague" cons

Re: Implementing Incremental View Maintenance

On Wed, 9 Sep 2020 14:22:28 +1200 Thomas Munro wrote: > > Therefore, usual update semantics (tuple locks and EvalPlanQual) and UPSERT > > can be used for optimization for some classes of view, but we don't have any > > other better idea than using table lock for views joining tables. We would >

Re: Inconsistent Japanese name order in v13 contributors list

On 2020/09/09 14:15, Etsuro Fujita wrote: Hi, Attached is a patch to standardize Japanese names as given-name-first in the v13 contributors list as before. Using given-name-first order is our consensus? I was thinking we have not reached that yet and our "vague" consensus was to use the nam

Re: v13: CLUSTER segv with wal_level=minimal and parallel index creation

Thank you for the checking. At Tue, 8 Sep 2020 21:05:43 -0700, Noah Misch wrote in > On Mon, Sep 07, 2020 at 07:47:09PM -0700, Noah Misch wrote: > After looking closer, I've moved the test to reindex_catalog.sql; see that > file's header comment for the reasons. One now needs this command: > >

Re: Global snapshots

On Wed, 9 Sep 2020 at 02:00, Alexey Kondratov wrote: > > On 2020-09-08 14:48, Fujii Masao wrote: > > On 2020/09/08 19:36, Alexey Kondratov wrote: > >> On 2020-09-08 05:49, Fujii Masao wrote: > >>> On 2020/09/05 3:31, Alexey Kondratov wrote: > > Attached is a patch, which implements a pla

Re: Inconsistency in determining the timestamp of the db statfile.

On 2020/09/09 12:04, Amit Kapila wrote: On Tue, Sep 8, 2020 at 7:03 PM Magnus Hagander wrote: On Tue, Sep 8, 2020 at 3:11 PM Fujii Masao wrote: On 2020/09/08 19:28, Magnus Hagander wrote: On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila mailto:amit.kapil...@gmail.com>> wrote: We use

Redundant tuple copy in tqueueReceiveSlot()

Hi, I am starting a new thread that continues with the following point that was discussed in [1] On Fri, 17 Jul 2020 at 09:05, Thomas Munro wrote: > > On Sun, Jul 12, 2020 at 7:25 AM Soumyadeep Chakraborty > wrote: > > Do you mean that we should have an implementation for > > get_minimal_t

Inconsistent Japanese name order in v13 contributors list

Hi, Attached is a patch to standardize Japanese names as given-name-first in the v13 contributors list as before. Best regards, Etsuro Fujita Standardize-Japanese-names.patch Description: Binary data

Re: New statistics for tuning WAL buffer size

On 2020-09-07 16:19, Fujii Masao wrote: On 2020/09/07 9:58, Masahiro Ikeda wrote: Thanks for the review and advice! On 2020-09-03 16:05, Fujii Masao wrote: On 2020/09/02 18:56, Masahiro Ikeda wrote: +/* -- + * Backend types + * -- You seem to forget to add "*/" into the above

Re: INSERT INTO SELECT, Why Parallelism is not selected?

On Thu, Jul 30, 2020 at 6:42 PM Amit Kapila wrote: > > On Thu, Jul 30, 2020 at 12:02 PM Amit Kapila wrote: > > > > On Wed, Jul 29, 2020 at 7:18 PM Robert Haas wrote: > > > > > > I still don't agree with this as proposed. > > > > > > + * For now, we don't allow parallel inserts of any form not ev

Re: Ideas about a better API for postgres_fdw remote estimates

On Wed, 9 Sep 2020 at 02:35, Tomas Vondra wrote > > I think that was the topic of *this* thread as started by Tom, but I now > realize Andrey steered it in the direction to allow re-using remote > stats. Which seems useful too, but it confused me a bit. > I didn't realize that the nearby thread

Re: VACUUM (INTERRUPTIBLE)?

Hi, On 2020-09-08 19:30:40 -0700, Andres Freund wrote: > It was fairly straight forward to implement the basics of > INTERRUPTIBLE. However it seems like it might not actually address my > main concern, i.e. making this reliably testable with isolation > tester. At least not the way I envisioned i

Re: v13: CLUSTER segv with wal_level=minimal and parallel index creation

On Mon, Sep 07, 2020 at 07:47:09PM -0700, Noah Misch wrote: > On Tue, Sep 08, 2020 at 10:43:32AM +0900, Kyotaro Horiguchi wrote: > > At Tue, 08 Sep 2020 09:13:53 +0900 (JST), Kyotaro Horiguchi > > wrote in > > > At Mon, 7 Sep 2020 02:32:55 -0700, Noah Misch wrote > > > in > > > > As a PoC, th

Re: Two fsync related performance issues?

On Thu, Sep 3, 2020 at 11:30 AM Thomas Munro wrote: > On Wed, May 27, 2020 at 12:31 AM Craig Ringer wrote: > > On Tue, 12 May 2020, 08:42 Paul Guo, wrote: > >> 1. StartupXLOG() does fsync on the whole data directory early in the crash > >> recovery. I'm wondering if we could skip some directori

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Sep 7, 2020 at 12:57 PM Dilip Kumar wrote: > > On Mon, Sep 7, 2020 at 12:00 PM Amit Kapila wrote: >> >> On Sat, Sep 5, 2020 at 8:55 PM Dilip Kumar wrote: >> > >> > >> > I have reviewed the changes and looks fine to me. >> > >> >> Thanks, I have pushed the last patch. Let's wait for a day

Re: Inconsistency in determining the timestamp of the db statfile.

On Tue, Sep 8, 2020 at 7:03 PM Magnus Hagander wrote: > > On Tue, Sep 8, 2020 at 3:11 PM Fujii Masao > wrote: >> >> >> >> On 2020/09/08 19:28, Magnus Hagander wrote: >> > >> > >> > On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila > > > wrote: >> > >> > We use the ti

Re: VACUUM (INTERRUPTIBLE)?

Hi, On 2020-09-08 18:37:05 -0400, Tom Lane wrote: > Andres Freund writes: > > So it doesn't seem that useful to not make manual analyze interruptible? > > I find the main attraction of this idea is that instead of saying > "autovacuum/autoanalyze have these magic behaviors", we can say > "autova

Re: Implementing Incremental View Maintenance

On Wed, Sep 9, 2020 at 12:29 PM Yugo NAGATA wrote: > I also thought it might be resolved using tuple locks and EvalPlanQual > instead of table level lock, but there is still a unavoidable case. For > example, suppose that tuple dR is inserted into R in T1, and dS is inserted > into S in T2. Also,

Re: file_fdw vs relative paths

Hi On 2020/09/07 2:31, Magnus Hagander wrote: On Mon, Aug 31, 2020 at 5:03 PM Bruce Momjian mailto:br...@momjian.us>> wrote: On Mon, Aug 31, 2020 at 01:16:05PM +0200, Magnus Hagander wrote: >     Bruce, I've applied and backpatched your docs patch for this. > > Gah, and of co

Re: default partition and concurrent attach partition

On Wed, Sep 9, 2020 at 7:41 AM Alvaro Herrera wrote: > On 2020-Sep-08, Amit Langote wrote: > > > Yeah, we need to make sure that ExecPartitionCheck gets a slot whose > > TupleDesc matches the partition's. Actually we do have such dedicated > > slots for partitions around (for both sub-partitioned

Re: Implementing Incremental View Maintenance

Hi Thomas, Thank you for your comment! On Sat, 5 Sep 2020 17:56:18 +1200 Thomas Munro wrote: > + /* > +* Wait for concurrent transactions which update this materialized view at > +* READ COMMITED. This is needed to see changes committed in other > +* transactions. No wait and raise

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Tue, Sep 08, 2020 at 09:02:38PM -0300, Alvaro Herrera wrote: > On 2020-Sep-08, Justin Pryzby wrote: > > > From 992e0121925c74d5c5a4e5b132cddb3d6b31da86 Mon Sep 17 00:00:00 2001 > > From: Justin Pryzby > > Date: Fri, 27 Mar 2020 17:50:46 -0500 > > Subject: [PATCH v27 1/5] Change REINDEX/CLUSTER

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On 2020-Sep-08, Justin Pryzby wrote: > From 992e0121925c74d5c5a4e5b132cddb3d6b31da86 Mon Sep 17 00:00:00 2001 > From: Justin Pryzby > Date: Fri, 27 Mar 2020 17:50:46 -0500 > Subject: [PATCH v27 1/5] Change REINDEX/CLUSTER to accept an option list.. > > ..like EXPLAIN (..), VACUUM (..), and ANALY

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Thu, Sep 03, 2020 at 09:43:51PM -0500, Justin Pryzby wrote: > And rebased on Michael's commit removing ReindexStmt->concurrent. Rebased on a6642b3ae: Add support for partitioned tables and indexes in REINDEX So now this includes the new functionality and test for reindexing a partitioned table

Re: WIP: WAL prefetch (another approach)

On Sat, Sep 05, 2020 at 12:05:52PM +1200, Thomas Munro wrote: On Wed, Sep 2, 2020 at 2:18 AM Tomas Vondra wrote: On Wed, Sep 02, 2020 at 02:05:10AM +1200, Thomas Munro wrote: >On Wed, Sep 2, 2020 at 1:14 AM Tomas Vondra > wrote: >> from the archive > >Ahh, so perhaps that's the key. Maybe. For

Re: VACUUM (INTERRUPTIBLE)?

Hi, On 2020-09-08 22:30:40 +0200, Magnus Hagander wrote: > One thing I've been wanting many times but never properly got around to > investigating how much work it would be to make happen, was to be able to > trigger an autovacuum manually (yeah, strange choice of terms). That is, > instead of the

Re: default partition and concurrent attach partition

On 2020-Sep-08, Amit Langote wrote: > Yeah, we need to make sure that ExecPartitionCheck gets a slot whose > TupleDesc matches the partition's. Actually we do have such dedicated > slots for partitions around (for both sub-partitioned and leaf > partitions), so we can simply use them instead of c

Re: VACUUM (INTERRUPTIBLE)?

Andres Freund writes: > So it doesn't seem that useful to not make manual analyze interruptible? I find the main attraction of this idea is that instead of saying "autovacuum/autoanalyze have these magic behaviors", we can say "autovacuum/autoanalyze use option FOO". So whatever behavior autoana

Re: default partition and concurrent attach partition

On 2020-Sep-08, Alvaro Herrera wrote: > Andres added to CC because of TTS interface: apparently calling > slot_getallattrs() on a virtual slot raises error that "getsomeattrs is > not required to be called on a virtual tuple table slot". I'm thinking > that this exposes implementation details tha

Re: More aggressive vacuuming of temporary tables

Andres Freund writes: > On 2020-09-08 15:24:54 -0400, Tom Lane wrote: >> Andres Freund writes: >>> But now I do wonder why we need to know whether the command is top level >>> or not? Why isn't the correct thing to instead look at what the current >>> backend's xmin is? Seems like you could just

Re: More aggressive vacuuming of temporary tables

Hi, On 2020-09-08 15:24:54 -0400, Tom Lane wrote: > Andres Freund writes: > > But now I do wonder why we need to know whether the command is top level > > or not? Why isn't the correct thing to instead look at what the current > > backend's xmin is? Seems like you could just replace > > *olde

SIGQUIT handling, redux

This is to pull together a couple of recent threads that are seemingly unrelated to $SUBJECT. Over in the long thread at [1] we've agreed to try to make the backend code actually do what assorted comments claim it does, namely allow SIGQUIT to be accepted at any point after a given process has est

Re: VACUUM (INTERRUPTIBLE)?

Hi, On 2020-09-08 17:36:00 -0300, Alvaro Herrera wrote: > On 2020-Sep-08, Andres Freund wrote: > > > That made me wonder if it'd be worthwhile to add an option that'd make > > user invoked VACUUM be interruptible by conflicting lock requests, just > > like autovacuum is. > > Yeah, I recall a req

Re: Ideas about a better API for postgres_fdw remote estimates

On Tue, Sep 08, 2020 at 05:55:09PM +0530, Ashutosh Bapat wrote: On Fri, 4 Sep 2020 at 20:27, Tomas Vondra wrote 4) I wonder if we actually want/need to simply output pg_statistic data verbatim like this. Is postgres_fdw actually going to benefit from it? I kinda doubt that, and my assumption

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On 08/09/2020 22:25, James Coleman wrote: On Wed, Aug 19, 2020 at 3:16 AM Heikki Linnakangas wrote: You could also apply the optimization for non-Const expressions, as long as they're stable (i.e. !contain_volatile_functions(expr)). Is that true? Don't we also have to worry about whether or

Re: VACUUM (INTERRUPTIBLE)?

On 2020-Sep-08, Andres Freund wrote: > That made me wonder if it'd be worthwhile to add an option that'd make > user invoked VACUUM be interruptible by conflicting lock requests, just > like autovacuum is. Yeah, I recall a request for this in the past, too. > So how about adding an INTERRUPTIBLE

Re: VACUUM (INTERRUPTIBLE)?

On Tue, Sep 8, 2020 at 8:49 PM Andres Freund wrote: > Hi, > > Jeff Janes in [1] found that I ([2]) broke autovacuum cancellations. It > obviously would be good to add a test for this, but it seems hard to > have that be reliable given how long it can take for autovacuum actually > get around to v

Re: default partition and concurrent attach partition

Hi, Andres added to CC because of TTS interface: apparently calling slot_getallattrs() on a virtual slot raises error that "getsomeattrs is not required to be called on a virtual tuple table slot". I'm thinking that this exposes implementation details that should not be necessary for a caller to

Re: Collation versioning

On Tue, Sep 08, 2020 at 09:33:26PM +0200, Christoph Berg wrote: > Re: Julien Rouhaud > > Here's the rationale for this new flag, extracted from the patch's commit > > message: > > > > Add a new amnostablecollorder flag in IndexAmRoutine. > > > > This flag indicates if the access method does not r

Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks

Bharath Rupireddy writes: > Attaching a patch with both the comments modification and changing > DEBUG3 to ERROR. make check and make world-check passes on this patch. I pushed this after simplifying the ereport down to an elog. I see no reason to consider this a user-facing error, so there's no

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

On Sat, Jul 18, 2020 at 03:15:32PM -0500, Justin Pryzby wrote: > Still waiting for feedback from a committer. This patch has been waiting for input from a committer on the approach I've taken with the patches since March 10, so I'm planning to set to "Ready" - at least ready for senior review. --

Re: Collation versioning

Re: Julien Rouhaud > Here's the rationale for this new flag, extracted from the patch's commit > message: > > Add a new amnostablecollorder flag in IndexAmRoutine. > > This flag indicates if the access method does not rely on a stable collation > ordering for deterministic collation, i.e. would n

Re: Boundary value check in lazy_tid_reaped()

On Tue, Sep 8, 2020 at 1:23 AM Masahiko Sawada wrote: > > > I wonder if you would also see a speed-up with a bsearch() replacement > > > that is inlineable, so it can inline the comparator (instead of > > > calling it through a function pointer). I wonder if something more > > > like (lblk << 32

Re: PATCH: Attempt to make dbsize a bit more consistent

I found the function "table_relation_size" is only used by buffer manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE" and "RELKIND_MATVIEW", i.e.         case RELKIND_RELATION:         case RELKIND_TOASTVALUE:         case RELKIND_MATVIEW:             {                 /*                  *

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On Wed, Aug 19, 2020 at 3:16 AM Heikki Linnakangas wrote: > > On 01/05/2020 05:20, James Coleman wrote: > > On Tue, Apr 28, 2020 at 8:25 AM Tomas Vondra > > wrote: > > ... > >> Any particular reasons to pick dynahash over simplehash? ISTM we're > >> using simplehash elsewhere in the executor (gro

Re: More aggressive vacuuming of temporary tables

Andres Freund writes: > But now I do wonder why we need to know whether the command is top level > or not? Why isn't the correct thing to instead look at what the current > backend's xmin is? Seems like you could just replace > *oldestXmin = XidFromFullTransactionId(ReadNextFullTransactionId()

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-06-07 11:24:50 +0300, Michail Nikolaev wrote: > Hello, hackers. > Andres, nice work! > > Sorry for the off-top. > > Some of my work [1] related to the support of index hint bits on > standby is highly interfering with this patch. > Is it safe to consider it committed and start rebasi

Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?

Hi, On 2020-07-29 22:26:04 -0500, David Pirotte wrote: > FWIW, we have been using pg_logical_emit_message to send application-level > events alongside our change-data-capture for about two years, and we would > move this part of our stack to pgoutput if message support was available. Yea, it's re

Re: INSERT ON CONFLICT and RETURNING

út 8. 9. 2020 v 12:34 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 08.09.2020 12:34, Pavel Stehule wrote: > > > > út 8. 9. 2020 v 11:06 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > >> I have performed comparison of different ways of implem

Re: Missing "Up" navigation link between parts and doc root?

On Sun, Sep 6, 2020 at 04:59:11PM +0200, Peter Eisentraut wrote: > On 2020-08-25 21:48, Bruce Momjian wrote: > > On Sat, Jul 4, 2020 at 08:47:53AM +0200, Fabien COELHO wrote: > > > > > > Hello Peter, > > > > > > > The original stylesheets explicitly go out of their way to do it that > > > > way

Re: Yet another fast GiST build

On 08/09/2020 21:33, Pavel Borisov wrote: > Thanks! Did you measure the quality of the built index somehow? The > ordering shouldn't make any difference to the build speed, but it > affects the shape of the resulting index and the speed of queries > against it. Again I've tri

Re: More aggressive vacuuming of temporary tables

Hi, On 2020-08-28 11:46:49 -0400, Tom Lane wrote: > It strikes me that when we are vacuuming a temporary table (which > necessarily will be one of our own session), we don't really need > to care what the global xmin horizon is. If we're not inside a > user transaction block, then there are no tu

VACUUM (INTERRUPTIBLE)?

Hi, Jeff Janes in [1] found that I ([2]) broke autovacuum cancellations. It obviously would be good to add a test for this, but it seems hard to have that be reliable given how long it can take for autovacuum actually get around to vacuum a specific table. That made me wonder if it'd be worthwhil

Re: Autovac cancellation is broken in v14

Hi, On 2020-08-27 14:35:06 -0700, Andres Freund wrote: > On 2020-08-27 16:20:30 -0400, Jeff Janes wrote: > > On Thu, Aug 27, 2020 at 3:10 PM Jeff Janes wrote: > > > > > If I create a large table with "CREATE TABLE ... AS SELECT ... from > > > generate_series(1,3e7)" with no explicit transactions

Re: Yet another fast GiST build

> > > Thanks! Did you measure the quality of the built index somehow? The > > ordering shouldn't make any difference to the build speed, but it > > affects the shape of the resulting index and the speed of queries > > against it. Again I've tried random select tests near axes and haven't noticed

Re: [Patch] ALTER SYSTEM READ ONLY

Hi, On 2020-08-28 15:53:29 -0400, Robert Haas wrote: > On Wed, Aug 19, 2020 at 6:28 AM Amul Sul wrote: > > Attached is a rebased on top of the latest master head (# 3e98c0bafb2). > > Does anyone, especially anyone named Andres Freund, have comments on > 0001? That work is somewhat independent of

Re: Rare deadlock failure in create_am test

On 2020-09-04 12:41:23 -0400, Tom Lane wrote: > Alvaro Herrera writes: > > On 2020-Sep-03, Tom Lane wrote: > >> I'm inclined to think that the best fix is to put > >> > >> begin; > >> lock table [fast_emp4000]; > >> ... > >> commit; > >> > >> around the DROP CASCADE. > > > Yeah, sounds good. >

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-09-08 16:44:17 +1200, Thomas Munro wrote: > On Tue, Sep 8, 2020 at 4:11 PM Andres Freund wrote: > > At first I was very confused as to why none of the existing tests have > > found this significant issue. But after thinking about it for a minute > > that's because they all use psql, a

Re: Optimising compactify_tuples()

On Wed, Sep 9, 2020 at 3:47 AM David Rowley wrote: > On Tue, 8 Sep 2020 at 12:08, Thomas Munro wrote: > > One thought is that if we're going to copy everything out and back in > > again, we might want to consider doing it in a > > memory-prefetcher-friendly order. Would it be a good idea to > >

Re: PROC_IN_ANALYZE stillborn 13 years ago

On Sat, Aug 29, 2020 at 8:06 PM Tom Lane wrote: > > Alvaro Herrera writes: > > I pushed despite the objection because it seemed that downstream > > discussion was largely favorable to the change, and there's a different > > proposal to solve the bloat problem for analyze; and also: > > Note that

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Sat, 2020-09-05 at 12:03 -0700, Peter Geoghegan wrote: > We should totally disable the preallocation stuff for external sorts > in any case. External sorts are naturally characterized by relatively > large, distinct batching of reads and writes -- preallocation cannot > help. Patch attached to

Re: [DOC] Document concurrent index builds waiting on each other

On Fri, Jul 31, 2020 at 2:51 PM James Coleman wrote: > > On Thu, Jul 16, 2020 at 7:34 PM David Johnston > wrote: > > > > The following review has been posted through the commitfest application: > > make installcheck-world: not tested > > Implements feature: not tested > > Spec compliant:

Re: Nicer error when connecting to standby with hot_standby=off

On Tue, Aug 18, 2020 at 12:25 PM Fujii Masao wrote: > Thanks for updating the patch! But it failed to be applied to the master > branch > cleanly because of the recent commit 0038f94387. So could you update the patch > again? Updated patch attached. James v3-0001-Improve-standby-connection-de

Re: Logical Replication - detail message with names of missing columns

Thanks for the comments. Attaching the v3 patch. On Tue, Sep 8, 2020 at 8:19 PM Alvaro Herrera wrote: > > This looks a bit fiddly. Would it be less cumbersome to use > quote_identifier here instead? > Changed. quote_identifier() adds quotes wherever necessary. > > Please do use errmsg_plural -

Re: Global snapshots

On 2020-09-08 14:48, Fujii Masao wrote: On 2020/09/08 19:36, Alexey Kondratov wrote: On 2020-09-08 05:49, Fujii Masao wrote: On 2020/09/05 3:31, Alexey Kondratov wrote: Attached is a patch, which implements a plain 2PC in the postgres_fdw and adds a GUC 'postgres_fdw.use_twophase'. Also it

Re: Optimising compactify_tuples()

On Mon, 7 Sep 2020 at 19:47, David Rowley wrote: > I wondered if we could get around that just by having another buffer > somewhere and memcpy the tuples into that first then copy the tuples > out that buffer back into the page. No need to worry about the order > we do that in as there's no chance

Re: Optimising compactify_tuples()

On Tue, 8 Sep 2020 at 12:08, Thomas Munro wrote: > > One thought is that if we're going to copy everything out and back in > again, we might want to consider doing it in a > memory-prefetcher-friendly order. Would it be a good idea to > rearrange the tuples to match line pointer order, so that th

Re: [POC] Fast COPY FROM command for the table with foreign partitions

On 2020-09-08 17:00, Amit Langote wrote: Hi Alexey, On Tue, Sep 8, 2020 at 6:29 PM Alexey Kondratov wrote: On 2020-09-08 10:34, Amit Langote wrote: > Any thoughts on the taking out the refactoring changes out of the main > patch as I suggested? > +1 for splitting the patch. It was rather diff

Re: Use for name of unnamed portal's memory context

On 2020-09-05 17:10, Tom Lane wrote: Julien Rouhaud writes: +1 too, and obviously patch looks good. The adjacent comment needs updating. committed with that change -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Serv

Re: proposal - reference to plpgsql_check from plpgsql doc

po 17. 8. 2020 v 11:03 odesílatel Pavel Stehule napsal: > > > po 17. 8. 2020 v 10:37 odesílatel Magnus Hagander > napsal: > >> >> >> On Mon, Aug 17, 2020 at 8:47 AM Pavel Stehule >> wrote: >> >>> Hi >>> >>> plpgsql_check extension is almost complete now. This extension is >>> available on all e

Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ...

On 2020-Sep-08, Laurenz Albe wrote: > We should at least have > > ALTER TABLE ... ADD PRIMARY KEY (id) INCLUDE (val); > > or something before we consider this patch. Agreed. Now the trick in this new command is to let the user change the included columns afterwards, which remains useful (sin

Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ...

On Mon, 2020-09-07 at 11:42 -0300, Alvaro Herrera wrote: > > This patch would provide a more convenient way to do that. > > Again, I am not sure if that justifies the effort. > > I have to admit I've seen cases where it'd be useful to have included > columns in primary keys. > > TBH I think if we

Re: Logical Replication - detail message with names of missing columns

On 2020-Sep-08, Bharath Rupireddy wrote: > + /* Find the remote attributes that are missing in the local relation. */ > + for (i = 0; i < remoterel->natts; i++) > + { > + if (!bms_is_member(i, localattnums)) > + { > + if (missingatts->len ==

Re: Logical Replication - detail message with names of missing columns

Thanks for the comments, v2 patch is attached. > > On Tue, Sep 8, 2020 at 6:50 AM Kyotaro Horiguchi > wrote: > > > > +1 for objective. However, that can be done simpler way that doesn't > > need additional loops by using bitmapset to hold missing remote > > attribute numbers. This also make the v

Re: default partition and concurrent attach partition

Hello Amit, On 2020-Sep-08, Amit Langote wrote: > On Tue, Sep 8, 2020 at 8:44 AM Alvaro Herrera > wrote: > > On 2020-Sep-07, Alvaro Herrera wrote: > > > > > Ah, it looks like we can get away with initializing the RRI to 0, and > > > then explicitly handle that case in ExecPartitionCheckEmitErro

Re: Disk-based hash aggregate's cost model

On Mon, Sep 07, 2020 at 01:55:28PM -0700, Jeff Davis wrote: On Sun, 2020-09-06 at 23:21 +0200, Tomas Vondra wrote: I've tested the costing changes on the simplified TPC-H query, on two different machines, and it seems like a clear improvement. Thank you. Committed. So yeah, the patched costi

Re: [PATCH] Automatic HASH and LIST partition creation

> The patch lacks documentation, because I expect some details may change > during discussion. Other than that, the feature is ready for review. > Hi, hackers! >From what I've read I see there is much interest in automatic partitions creation. (Overall discussion on the topic is partitioned into t

Re: [POC] Fast COPY FROM command for the table with foreign partitions

Hi Alexey, On Tue, Sep 8, 2020 at 6:29 PM Alexey Kondratov wrote: > On 2020-09-08 10:34, Amit Langote wrote: > > Any thoughts on the taking out the refactoring changes out of the main > > patch as I suggested? > > > > +1 for splitting the patch. It was rather difficult for me to > distinguish cha

Re: Auto-vectorization speeds up multiplication of large-precision numerics

Amit Khandekar writes: > Thanks. I must admit it did not occur to me that I could have very > well installed clang on my linux machine and tried compiling this > file, or tested with some older gcc versions. I think I was using gcc > 8. Do you know what was the gcc compiler version that gave these

Re: PATCH: Attempt to make dbsize a bit more consistent

On Thu, Aug 27, 2020 at 9:39 AM wrote: > > Hi all, > > this minor patch is attempting to force the use of the tableam api in dbsize > where ever it is required. > > Apparently something similar was introduced for toast relations only. > Intuitively it seems that the distinction between a table a

Re: Resetting spilled txn statistics in pg_stat_replication

On Tue, Sep 8, 2020 at 7:53 AM Masahiko Sawada wrote: > > On Mon, 7 Sep 2020 at 15:24, Amit Kapila wrote: > > > > This patch needs a rebase. I don't see this patch in the CF app. I > > hope you are still interested in working on this. > > Thank you for reviewing this patch! > > I'm still going to

Re: Inconsistency in determining the timestamp of the db statfile.

On Tue, Sep 8, 2020 at 3:11 PM Fujii Masao wrote: > > > On 2020/09/08 19:28, Magnus Hagander wrote: > > > > > > On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila > wrote: > > > > We use the timestamp of the global statfile if we are not able to > > determine it f

Re: Transactions involving multiple postgres foreign servers, take 2

On Mon, Sep 7, 2020 at 2:29 PM Fujii Masao wrote: > > #2 > Originally when there was the FDW access in the transaction, > PREPARE TRANSACTION on that transaction failed with an error. The patch > allows PREPARE TRANSACTION and COMMIT/ROLLBACK PREPARED > even when FDW access occurs in the transacti

Re: Inconsistency in determining the timestamp of the db statfile.

On 2020/09/08 19:28, Magnus Hagander wrote: On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila mailto:amit.kapil...@gmail.com>> wrote: We use the timestamp of the global statfile if we are not able to determine it for a particular database either because the entry for that database does

Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks

On Mon, Sep 7, 2020 at 8:50 PM Tom Lane wrote: > > I think there is agreement that we're not going to change > cancel_before_shmem_exit's restriction to only allow LIFO popping. > So we should improve its comment to explain why. The other thing > that seems legitimately on-the-table for this CF e

Case for Improved Costing for Index Only Scans?

While running a simple SELECT statement on a table where I expected indexonly scan to be preferred over sequential scan, the planner kept on selecting the sequential scan. Looking at the EXPLAIN output, it seemed obvious that the cost of indexonly was exceeding that of sequential scan. So the plann

Re: Ideas about a better API for postgres_fdw remote estimates

On Fri, 4 Sep 2020 at 20:27, Tomas Vondra wrote > > > 4) I wonder if we actually want/need to simply output pg_statistic data > verbatim like this. Is postgres_fdw actually going to benefit from it? I > kinda doubt that, and my assumption was that we'd return only a small > subset of the data, ne

Re: Evaluate expression at planning time for two more cases

On Tue, 8 Sep 2020 at 07:16, Tom Lane wrote: > > > I'm not sure what I think about Ashutosh's ideas about doing this > somewhere else than eval_const_expressions. I do not buy the argument > that it's interesting to do this separately for each child partition. > Child partitions that have attnot

Re: Parallel worker hangs while handling errors.

On Thu, Sep 3, 2020 at 5:29 PM Tom Lane wrote: > Concretely, something about like this (I just did the bgwriter, but > we'd want the same in all the background processes). I tried to > respond to Robert's complaint about the inaccurate comment just above > sigsetjmp, too. > > This passes check-wo

Re: Global snapshots

On 2020/09/08 19:36, Alexey Kondratov wrote: On 2020-09-08 05:49, Fujii Masao wrote: On 2020/09/05 3:31, Alexey Kondratov wrote: Attached is a patch, which implements a plain 2PC in the postgres_fdw and adds a GUC 'postgres_fdw.use_twophase'. Also it solves these errors handling issues ab

RE: extension patch of CREATE OR REPLACE TRIGGER

Hi, Peter-San I've fixed all except one point. > My only remaining comments are for trivial stuff: Not trivial but important. > COMMENT trigger.c (tab alignment) > > @@ -184,6 +185,13 @@ CreateTrigger(CreateTrigStmt *stmt, const char > *queryString, > char*oldtablename = NULL; > char

Re: Division in dynahash.c due to HASH_FFACTOR

Hi Thomas, Tomas :), Alvaro, hackers, >> > After removing HASH_FFACTOR PostgreSQL still compiles... Would >> > removing it break some external API/extensions ? >> >> FWIW, HASH_FFACTOR has *never* been used in Postgres core code. [..] >> I think if we know that there's a 4% performance increase b

Re: INSERT ON CONFLICT and RETURNING

út 8. 9. 2020 v 12:34 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 08.09.2020 12:34, Pavel Stehule wrote: > > > > út 8. 9. 2020 v 11:06 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > >> I have performed comparison of different ways of implem

  1   2   >