Re: Needless additional partition check in INSERT?

Hi David. On 2018/05/10 18:56, David Rowley wrote: > On 10 May 2018 at 17:42, Simon Riggs wrote: >> Patch is good. >> >> The cause of this oversight is the lack of comments to explain the >> original coding, so we need to correct that in this patch, please. > > Thanks for

Re: Should we add GUCs to allow partition pruning to be disabled?

Hi. On 2018/05/11 4:45, Alvaro Herrera wrote: > I'm thinking something like this. +1 to this more radical overhaul of this part of the documentation. > The examples for runtime pruning are lame -- in the first, the text says > "watch out for Subplans Removed" and then the example provided

Re: [HACKERS] Surjective functional indexes

On Thursday, February 1, 2018, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > Old + New for check = 2 >> plus calculate again in index = 3 >> > > Yes, we have to calculate the value of index expression for original and > updated version of the record. If them are equal, then it is

Re: Should we add GUCs to allow partition pruning to be disabled?

On 2018/05/11 2:13, Robert Haas wrote: > On Thu, May 10, 2018 at 12:58 PM, Alvaro Herrera > wrote: >> David G. Johnston wrote: >>> As a user I don't really need to know which model is implemented and the >>> name doesn't necessarily imply the implementation. Pruning

Re: PANIC during crash recovery of a recently promoted standby

On Thu, May 10, 2018 at 10:52:12AM +0530, Pavan Deolasee wrote: > I propose that we should always clear the minRecoveryPoint after promotion > to ensure that crash recovery always run to the end if a just-promoted > standby crashes before completing its first regular checkpoint. A WIP patch > is

Re: [HACKERS] Surjective functional indexes

On 2018-05-10 23:25:58 -0400, Robert Haas wrote: > On Thu, Mar 1, 2018 at 2:48 PM, Andres Freund wrote: > > I still don't think, as commented upon by Tom and me upthread, that we > > want this feature in the current form. > > Was this concern ever addressed, or did the patch

Re: [HACKERS] Surjective functional indexes

On Thu, Mar 1, 2018 at 2:48 PM, Andres Freund wrote: > I still don't think, as commented upon by Tom and me upthread, that we > want this feature in the current form. Was this concern ever addressed, or did the patch just get committed anyway? -- Robert Haas EnterpriseDB:

Re: Should we add GUCs to allow partition pruning to be disabled?

On 11 May 2018 at 08:05, Robert Haas wrote: > > On Thu, May 10, 2018 at 3:45 PM, Alvaro Herrera > wrote: > > The examples for runtime pruning are lame -- in the first, the text says > > "watch out for Subplans Removed" and then the example

Re: [HACKERS] Clock with Adaptive Replacement

On Wed, Apr 25, 2018 at 6:31 PM, Andrey Borodin wrote: > 4. Using O_DIRECT while writing data files One interesting thing about O_DIRECT that I haven't seen mentioned in these discussions: POSIX effectively requires writes to the same file to be serialised, meaning in

Re: SQL:2011 Valid-Time Support

On Tue, May 8, 2018 at 7:13 PM, Peter Eisentraut wrote: > On 5/8/18 11:31, Tom Lane wrote: >> Paul Howells writes: >>> Has there been or is there any current effort to implement SQL:2011 >>> valid-time support in Postgres? >> >>

Re: Global snapshots

On Fri, May 4, 2018 at 2:11 AM, Stas Kelvich wrote: > > >> On 3 May 2018, at 18:28, Masahiko Sawada wrote: >> >> On Wed, May 2, 2018 at 1:27 AM, Stas Kelvich >> wrote: >>> 1) To achieve commit atomicity of different

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

"Jonathan S. Katz" writes: >> On May 10, 2018, at 12:37 PM, Tom Lane wrote: >> OTOH, in view of Josh's old gripe, maybe it could be argued to be a bug >> fix, at least on platforms where it does anything. > Read back to get some

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

> On May 10, 2018, at 12:37 PM, Tom Lane wrote: > > Andres Freund writes: >> On 2018-05-10 12:18:19 -0400, Tom Lane wrote: >>> Next question is what to do with this. Do we want to sit on it till >>> v12, or sneak it in now? > >> Is there a decent

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

Robert Haas writes: > On Thu, May 10, 2018 at 3:37 PM, Tom Lane wrote: >> Yeah, I had hoped that this might make a noticeable difference on slower >> buildfarm animals, but some testing shows that it's more likely to be >> barely above the noise floor.

Re: Why does load_external_function() return PGFunction?

On 2018-05-10 16:41:53 -0400, Robert Haas wrote: > On Mon, Mar 26, 2018 at 4:16 PM, Andres Freund wrote: > > I dug up a thread about the introduction of the warning: > > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00423.html > > > > Sounds like we should add something like >

Re: Why does load_external_function() return PGFunction?

On Mon, Mar 26, 2018 at 4:16 PM, Andres Freund wrote: > I dug up a thread about the introduction of the warning: > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00423.html > > Sounds like we should add something like > typedef void (*GenericFuncPtr) (void); > or such? Similar

Re: Proposal: http2 wire format

On Mon, Mar 26, 2018 at 7:51 PM, Craig Ringer wrote: > There's been no visible consideration of overheads and comparison with > existing v3 protocol. Personally I'm fine with adding some protocol overhead > in bytes terms; low latency links have the bandwidth not to care

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On Thu, May 10, 2018 at 3:37 PM, Tom Lane wrote: > Yeah, I had hoped that this might make a noticeable difference on slower > buildfarm animals, but some testing shows that it's more likely to be > barely above the noise floor. Any idea why? -- Robert Haas EnterpriseDB:

Re: Should we add GUCs to allow partition pruning to be disabled?

I'm thinking something like this. The examples for runtime pruning are lame -- in the first, the text says "watch out for Subplans Removed" and then the example provided doesn't show one. (That example is probably exercising the wrong thing.) Anyway, wording suggestions for 5.10.4 and 5.10.5 in

Re: ts_rewrite in 10.4

> On May 10, 2018, at 10:16 AM, Tom Lane wrote: > > Douglas Doole writes: >> The release notes say: >> ALTER FUNCTION pg_catalog.ts_rewrite(tsquery, tsquery, tsquery) PARALLEL >> UNSAFE; > >> But when I pull pg_proc.h from 10.4, I find: >> DATA(insert

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

Andres Freund writes: > On 2018-05-10 12:18:19 -0400, Tom Lane wrote: >> Next question is what to do with this. Do we want to sit on it till >> v12, or sneak it in now? > Is there a decent argument for sneaking it in? I don't really have an > opinion. I don't think it'd

Re: pg_ugprade test failure on data set with column with default value with type bit/varbit

On Fri, Mar 30, 2018 at 5:36 AM, Paul Guo wrote: > There is no diff in functionality of the dump SQLs, but it is annoying. The > simple patch below could fix this. Thanks. > > --- a/src/backend/utils/adt/ruleutils.c > +++ b/src/backend/utils/adt/ruleutils.c > @@ -9389,7 +9389,7

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Tue, Feb 27, 2018 at 2:21 AM, Masahiko Sawada wrote: > I might be missing your point. As for API breaking, this patch doesn't > break any existing FDWs. All new APIs I proposed are dedicated to 2PC. > In other words, FDWs that work today can continue working after this >

Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, May 10, 2018 at 1:51 PM, Alvaro Herrera wrote: > David G. Johnston wrote: >> Seems like if it stays the name is good - but at this point no has voiced >> opposition to removing it and making the name a moot point. > > If we think the probability of bugs is 0%,

Re: Should we add GUCs to allow partition pruning to be disabled?

David G. Johnston wrote: > ​Seems like if it stays the name is good - but at this point no has voiced > opposition to removing it and making the name a moot point. If we think the probability of bugs is 0%, then I'm all for removing it. I don't. I vote to remove the GUC in a couple of releases,

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

Hi, On 2018-05-10 12:18:19 -0400, Tom Lane wrote: > Next question is what to do with this. Do we want to sit on it till > v12, or sneak it in now? Is there a decent argument for sneaking it in? I don't really have an opinion. I don't think it'd really be arguable that this'll make testing

Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, May 10, 2018 at 10:13 AM, Robert Haas wrote: > On Thu, May 10, 2018 at 12:58 PM, Alvaro Herrera > wrote: > > David G. Johnston wrote: > >> As a user I don't really need to know which model is implemented and the > >> name doesn't

Re: ts_rewrite in 10.4

Douglas Doole writes: > The release notes say: > ALTER FUNCTION pg_catalog.ts_rewrite(tsquery, tsquery, tsquery) PARALLEL > UNSAFE; > But when I pull pg_proc.h from 10.4, I find: > DATA(insert OID = 3684 ( ts_rewrite PGNSP PGUID 12 1 0 0 0 f f f f t f i s > 3 0 3615 "3615

Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, May 10, 2018 at 12:58 PM, Alvaro Herrera wrote: > David G. Johnston wrote: >> As a user I don't really need to know which model is implemented and the >> name doesn't necessarily imply the implementation. Pruning seems to be the >> commonly-used term for this

ts_rewrite in 10.4

As I was double checking that the new function marking from 10.4 merged correctly to our fork, I noticed that one of the ts_rewrite entries looks wrong. The release notes say: ALTER FUNCTION pg_catalog.ts_rewrite(tsquery, tsquery, tsquery) PARALLEL UNSAFE; But when I pull pg_proc.h from 10.4, I

Re: Should we add GUCs to allow partition pruning to be disabled?

David G. Johnston wrote: > As a user I don't really need to know which model is implemented and the > name doesn't necessarily imply the implementation. Pruning seems to be the > commonly-used term for this feature and we should stick with that. I agree with this conclusion. So we have it

Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, May 10, 2018 at 8:57 AM, Alvaro Herrera wrote: > b) by default, no partitions are > scanned, and we examine the query to determine which ones must be > scanned. > ​There is an element of logic that says "by default, no partitions are scanned" is not a

Re: Should we add GUCs to allow partition pruning to be disabled?

David Rowley wrote: > On 1 May 2018 at 21:44, Amit Langote wrote: > > About the patch in general, it seems like the newly added documentation > > talks about "Partition Pruning" as something that *replaces* constraint > > exclusion. But, I think "Partition Pruning"

Re: Considering signal handling in plpython again

On Thu, May 10, 2018 at 10:50 AM, Heikki Linnakangas wrote: > I came up with the attached patch, which is similar to Mario's, but it > introduces a new "hook" for this. I'd rather have the hook be executed whenever ProcessInterrupts() is called, rather than only in the

Re: Considering signal handling in plpython again

On 10/05/18 09:32, Hubert Zhang wrote: Hi all, I want to support canceling for a plpython query which may be a busy loop. I found some discussions on pgsql-hackers 2 years ago. Below is the link.

Re: Should we add GUCs to allow partition pruning to be disabled?

Robert Haas wrote: > In defense of constraint exclusion, let me note that constraint > exclusion is not restricted to inheritance cases. It could eliminate > the need to scan a completely unpartitioned table if the WHERE clause > can be refuted by CHECK constraints. It could eliminate the need

Re: Indexes on partitioned tables and foreign partitions

On Wed, May 9, 2018 at 10:20 PM, Amit Langote wrote: > But it seems I've misinterpreted what he was saying. He doesn't seem to > be saying anything about how or whether we enforce the unique constraint > on foreign tables. Only that if someone creates a constraint

Re: Should we add GUCs to allow partition pruning to be disabled?

On Wed, May 9, 2018 at 10:10 PM, David Rowley wrote: > On 10 May 2018 at 14:01, Alvaro Herrera wrote: >> I'm thinking something a bit more radical. First, since partition >> pruning is the future and constraint exclusion is soon to be a

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

(2018/05/10 13:04), Ashutosh Bapat wrote: On Wed, May 9, 2018 at 5:20 PM, Etsuro Fujita wrote: (2018/04/25 18:51), Ashutosh Bapat wrote: Actually I noticed that ConvertRowtypeExpr are used to cast a child's whole row reference expression (not just a Var node)

postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers

While doing a bit more review of the partitionwise-join-fix patch, I noticed $SUBJECT. Here is an example that causes an assertion failure "TRAP: FailedAssertion("!(foreignrel)", File: "postgres_fdw.c", Line: 2213)": postgres=# create table t1 (a int, b text); CREATE TABLE postgres=# create

Re: Shared PostgreSQL libraries and symbol versioning

On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote: > Stephen Frost writes: > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > >> On 4/5/18 02:04, Pavel Raiskup wrote: > >>> As a followup thought; there are probably two major obstacles ATM > >>> - the

Re: doc fixes: vacuum_cleanup_index_scale_factor

thanks to everyone, pushed -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Needless additional partition check in INSERT?

On 10 May 2018 at 17:42, Simon Riggs wrote: > Patch is good. > > The cause of this oversight is the lack of comments to explain the > original coding, so we need to correct that in this patch, please. Thanks for looking. Yeah, the comments do need work. In order to make

Re: [HACKERS] path toward faster partition pruning

On 09-05-2018 17:30, Alvaro Herrera wrote: Marina Polyakova wrote: Hello everyone in this thread! I got a similar server crash as in [1] on the master branch since the commit 9fdb675fc5d2de825414e05939727de8b120ae81 when the assertion fails because the second argument ScalarArrayOpExpr is

Test for trigger condition accessing system attributes

Hi, I was investigating the cases when the system attributes are accessed beyond the scans. After investigating set_plan_references(), I thought that we never access system attributes beyond scans. This lead me to assume that EEOP_INNER/OUTER_SYSVAR are not needed since we do not access system

Re: doc fixes: vacuum_cleanup_index_scale_factor

On 05/08/2018 02:05 PM, Justin Pryzby wrote: 3rd iteration ; thanks for bearing with me. On Tue, May 08, 2018 at 12:35:00PM +0300, Alexander Korotkov wrote: Hi, Justin! Thank you for revising documentation patch. On Mon, May 7, 2018 at 7:55 PM, Justin Pryzby wrote: +

Re: Needless additional partition check in INSERT?

On 2018/05/10 14:42, Simon Riggs wrote: > On 10 May 2018 at 05:33, David Rowley wrote: >> On 10 May 2018 at 16:13, Amit Langote wrote: >>> The patch to ExecInsert looks good, but I think we also need to do the >>> same thing in

Considering signal handling in plpython again

Hi all, I want to support canceling for a plpython query which may be a busy loop. I found some discussions on pgsql-hackers 2 years ago. Below is the link. https://www.postgresql.org/message-id/cafywgj3+xg7ecl2nu-mxx6p+o6c895pm3myz-b+9n9dffeh...@mail.gmail.com Mario wrote a patch to fix this