Re: Postgres 11 release notes

(2018/05/16 4:45), Bruce Momjian wrote: On Tue, May 15, 2018 at 02:26:33PM +0900, Etsuro Fujita wrote: (2018/05/12 0:08), Bruce Momjian wrote: I have committed the first draft of the Postgres 11 release notes. I will add more markup soon. You can view the most current version here:

Re: NaNs in numeric_power (was Re: Postgres 11 release notes)

On 15 May 2018 at 22:55, Tom Lane wrote: > David Rowley writes: >> On 16 May 2018 at 02:01, Tom Lane wrote: >>> I'm not particularly fussed about getting credit for that. However, >>> looking again at how that patch series

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

I was wondering if anyone knows the proper way to write a benchmarking test for the @>> operator. I used the below script in my previous attempt https://gist.github.com/markrofail/174ed370a2f2ac24800fde2fc27e2d38 The script does the following steps: 1. Generate Table A with 5 rows 2. Generate

Re: Postgres 11 release notes

On 16/05/18 07:22, Michael Paquier wrote: On Mon, May 14, 2018 at 08:45:44PM -0400, Bruce Momjian wrote: What TLS does is to mix the offered ciphers into the negotiation hash so a man-in-the-middle can't pretend it doesn't support something. Could we do something like that here? I have to

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

Fujita-san, On 2018/05/16 18:35, Etsuro Fujita wrote: > (2018/05/14 9:45), Amit Langote wrote: >> On 2018/05/11 21:48, Etsuro Fujita wrote: >>> (2018/05/11 16:19), Amit Langote wrote: On 2018/05/11 16:12, Amit Langote wrote: > Just to clarify, does this problem only arise because there

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

(2018/05/14 9:45), Amit Langote wrote: > On 2018/05/11 21:48, Etsuro Fujita wrote: >> (2018/05/11 16:19), Amit Langote wrote: >>> On 2018/05/11 16:12, Amit Langote wrote: Just to clarify, does this problem only arise because there is a pushed down join involving the child? That is, does

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

On Wed, May 16, 2018 at 4:01 PM, Etsuro Fujita wrote: > So we could really minimize the code change and avoid the additional overhead caused by the is_converted_whole_row_reference test added to pull_var_clause. I think the latter would

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

Alexander Korotkov writes: > On Wed, May 16, 2018 at 1:41 AM, Tom Lane wrote: >> Perhaps there is a case for adding an additional flag to allow specifying >> "I can't support ORDER BY DESC", but I'm not in a big hurry to do so. >> I think there

Re: Should total_pages be calculated after partition pruning and constraint exclusion?

David Rowley writes: > On 16 May 2018 at 11:04, Tom Lane wrote: >> No, it should go under "planner improvement". If this were a bug fix, >> it'd be a candidate for back-patch, which IMO it's not --- if only >> because of the risk of plan

Re: libpq compression

Hello! I have noticed that psql --help lack -Z|--compression option. Also it would be nice to have option like --compression-level in psql and pgbench. On 03/30/2018 03:53 PM, Konstantin Knizhnik wrote: Hi hackers, One of our customers was managed to improve speed about 10 times by using

Removing unneeded self joins

Hi hackers, There is a join optimization we don't do -- removing inner join of a table with itself on a unique column. Such joins are generated by various ORMs, so from time to time our customers ask us to look into this. Most recently, it was discussed on the list in relation to an article

Re: libpq compression

On 16.05.2018 18:09, Grigory Smolkin wrote: Hello! I have noticed that psql --help lack -Z|--compression option. Also it would be nice to have option like --compression-level in psql and pgbench. Thank you for this notice. Updated and rebased patch is attached. Concerning specification of

Re: Considering signal handling in plpython again

There are remaining two problems 1. Do we need to consider when to delete the extension hook or it's not necessary? As the destroy function _PG_fini doesn't work, I cannot find a good place to reset to hook gracefully. I tested the drop language plpythonu statement which will not remove

Re: Memory unit GUC range checks

On Wed, May 16, 2018 at 3:49 PM, Heikki Linnakangas wrote: > On 16/05/18 15:19, Heikki Linnakangas wrote: > >> $ postmaster -c track_activity_query_size=1024TB >> FATAL: invalid value for parameter "track_activity_query_size": "1024TB" >> HINT: Valid units for this parameter

Re: log_min_messages shows debug instead of debug2

On Tue, May 15, 2018 at 4:46 AM, Ideriha, Takeshi wrote: > I noticed that if log_min_messages is set to ‘debug2’, it shows ‘debug’ > instead of debug2. > > Patch attached. Seems worth changing to me. Anyone else think differently? -- Robert Haas EnterpriseDB:

Re: log_min_messages shows debug instead of debug2

Robert Haas writes: > On Tue, May 15, 2018 at 4:46 AM, Ideriha, Takeshi > wrote: >> I noticed that if log_min_messages is set to ‘debug2’, it shows ‘debug’ >> instead of debug2. > Seems worth changing to me. Anyone else think differently?

Re: index scan over composite type

Teodor Sigaev writes: > Thank you. Seems, it works, at least I can't find a counter-example for that. Will push, thanks for reviewing. regards, tom lane

Re: parallel foreign scan

> I think you are trying collecting data from multple kafka > server. This means each server has a dedicate foreign table on a > dedicate foreign server. Parallel execution doesn't fit in that > case since it works on single base relation (or a > table). Parallel append/merge append look a bit

Re: Considering signal handling in plpython again

On 16 May 2018 16:50:24 EEST, Hubert Zhang wrote: >There are remaining two problems > >1. Do we need to consider when to delete the extension hook or it's not >necessary? No, PostgreSQL never unloads shared libraries, so that can be ignored. We used to, and that's what

Re: Removing unneeded self joins

Alexander Kuzmenkov writes: > There is a join optimization we don't do -- removing inner join of a > table with itself on a unique column. Such joins are generated by > various ORMs, so from time to time our customers ask us to look into > this. Most recently, it

Re: index scan over composite type

Thank you. Seems, it works, at least I can't find a counter-example for that. Tom Lane wrote: Teodor Sigaev writes: I'm not understand why postgres prefers to sort table instead of using index only scan when query is a simple inner join on composite type. Query with equality

Re: Incorrect comment in get_partition_dispatch_recurse

On Mon, May 14, 2018 at 12:57 AM, David Rowley wrote: > I noticed that a comment in get_partition_dispatch_recurse claims that: > > "it contains the > * leaf partition's position in the global list *leaf_part_oids minus 1" > > The "minus 1" part is incorrect. It

Re: Oddity in COPY FROM handling of check constraints on partition tables

On Tue, Mar 27, 2018 at 9:00 AM, Etsuro Fujita wrote: > Attached is a patch for fixing this issue. This no longer applies. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

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

On Fri, May 11, 2018 at 8:46 AM, Etsuro Fujita wrote: > I added an assertion test to make_modifytable to match that in > create_modifytable_path. Attached is an updated version of the patch. Committed. Was it just good luck that this ever worked at all? I mean: -

Re: NaNs in numeric_power (was Re: Postgres 11 release notes)

Dean Rasheed writes: > On 15 May 2018 at 22:55, Tom Lane wrote: >> Here's a proposed patch for that. > In the case 1 ^ NaN = 1, what should the result scale be? The result is exact, so I don't see a reason to be worried about its scale. Messing

Re: Postgres 11 release notes

On 2018-May-15, Bruce Momjian wrote: > On Wed, May 16, 2018 at 09:01:35AM +0900, Tatsuo Ishii wrote: > > There's a small typo. > > > > > Add support for with huge(large) pages on Windows (Takayuki Tsunakawa, > > > Thomas Munro) > > > > I think a space between "huge" and "(large)" is needed. >

Re: Optimze usage of immutable functions as relation

Hello, I reworked a patch to make more stable in different cases. I decided to use simplify_function instead of eval_const_expression to prevent inlining of the function. The only possible outputs of the simplify_function are Const node and NULL. Also, I block pre-evaluation of functions with

Re: [PROPOSAL] Shared Ispell dictionaries

On Wed, May 16, 2018 at 7:36 AM, Arthur Zakirov wrote: >> I don't quite understand the problem you're trying to solve here, but: >> >> 1. Unless dsm_pin_segment() is called, a DSM segment will >> automatically be removed when there are no remaining mappings. >> >> 2.

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

On Thu, May 10, 2018 at 10:22 PM, David Rowley wrote: > Here's a recap of the current way to determine where the pruning occurred: > > Phase 1: Plan time pruning: > > EXPLAIN/EXPLAIN ANALYZE shows Append/MergeAppend/ModifyTable shows > fewer subnodes than there are

Re: Memory unit GUC range checks

Hi! On Wed, May 16, 2018 at 3:19 PM, Heikki Linnakangas wrote: > I played around with the GUC memory units, specifically to test the new > GUC_UNIT_BYTES flag (commit 6e7baa32): > > $ postmaster -c track_activity_query_size=1024kB > FATAL: 1048576 is outside the valid range

Re: Postgres 11 release notes

On Wed, May 16, 2018 at 01:09:07PM +0300, Heikki Linnakangas wrote: > I have to agree with Bruce, that it's pretty useless to implement channel > binding, if there is no way to require it in libpq. IMHO that must be > fixed. Wouldn't we want to also do something for the case where a client is

Re: Memory unit GUC range checks

On 16/05/18 15:19, Heikki Linnakangas wrote: $ postmaster -c track_activity_query_size=1024TB FATAL: invalid value for parameter "track_activity_query_size": "1024TB" HINT: Valid units for this parameter are "kB", "MB", "GB", and "TB". ... The HINT in the last message seems wrong: the hint

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

(2018/05/14 15:34), Ashutosh Bapat wrote: On Mon, May 14, 2018 at 10:21 AM, Ashutosh Bapat wrote: On Fri, May 11, 2018 at 6:31 PM, Etsuro Fujita wrote: Here's the query. explain verbose select * from fprt1 t1 join fprt2 t2 on

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

(2018/05/16 18:40), Amit Langote wrote: > On 2018/05/16 18:35, Etsuro Fujita wrote: >> I don't object to back-patching. Should I remove this from the open >> items list for PG11? > > Perhaps, keep on the page but in Older Bugs section? OK, I'll move to Older Bugs on that page and add to the

Memory unit GUC range checks

Hi, I played around with the GUC memory units, specifically to test the new GUC_UNIT_BYTES flag (commit 6e7baa32): $ postmaster -c track_activity_query_size=1024kB FATAL: 1048576 is outside the valid range for parameter "track_activity_query_size" (100 .. 102400) $ postmaster -c

Re: Flexible permissions for REFRESH MATERIALIZED VIEW

On Tue, May 15, 2018 at 6:07 PM, Tom Lane wrote: > That seems like an awful lot of work to handle what's still going to be > a pretty small set of permissions. Every permission we add is going to > have to be enforced in the C code, and it'll break applications to some >

Re: [PROPOSAL] Shared Ispell dictionaries

Hello, On Tue, May 15, 2018 at 05:02:43PM -0400, Robert Haas wrote: > On Tue, Mar 27, 2018 at 8:19 AM, Arthur Zakirov > wrote: > > Yes, there is dsm_pin_mapping() for this. But it is necessary to keep a > > segment even if there are no attached processes. From 0003: > >

Re: Global snapshots

> On 15 May 2018, at 15:53, Robert Haas wrote: > > Actually, I think if we're going to pursue that approach, we ought to > back off a bit from thinking about global snapshots and think about > what kind of general mechanism we want. For example, maybe you can > imagine

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

On Wed, May 16, 2018 at 1:41 AM, Tom Lane wrote: > Nikita Glukhov writes: > > Experimenting with the new pluggable storage API, I found that > amcanbackward > > flag is not checked in build_index_paths() before > > build_index_pathkeys(...

Re: Postgres 11 release notes

On 2018-May-16, Magnus Hagander wrote: > On Wed, May 16, 2018 at 4:08 PM, Alvaro Herrera > wrote: > > I'm not sure why we say "huge (large) pages". The natural term for > > Windows is "large-pages", > > https://msdn.microsoft.com/en-us/library/windows/desktop/ > >

Re: Postgres 11 release notes

On Wed, May 16, 2018 at 6:24 PM, Alvaro Herrera wrote: > On 2018-May-16, Magnus Hagander wrote: > > > On Wed, May 16, 2018 at 4:08 PM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > > > > I'm not sure why we say "huge (large) pages". The natural term for > >

Re: log_min_messages shows debug instead of debug2

On Wed, May 16, 2018 at 11:28 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, May 15, 2018 at 4:46 AM, Ideriha, Takeshi >> wrote: >>> I noticed that if log_min_messages is set to ‘debug2’, it shows ‘debug’ >>>

Re: Problem while updating a foreign table pointing to a partitioned table on foreign server

On Mon, Apr 16, 2018 at 7:35 AM, Ashutosh Bapat wrote: > It does fix the problem. But the patch as is interferes with the way > we handle tableoid currently. That can be seen from the regression > diffs that the patch causes. RIght now, every tableoid reference

Re: Removing unneeded self joins

On Wed, May 16, 2018 at 12:08 PM, Tom Lane wrote: > Alexander Kuzmenkov writes: >> There is a join optimization we don't do -- removing inner join of a >> table with itself on a unique column. Such joins are generated by >> various ORMs, so from

Re: Memory unit GUC range checks

On 16/05/18 16:35, Alexander Korotkov wrote: I also think it would be nice to show units in the valid range. I image that if I would see such message at the first time, then I would try to reverse-engineer units from input value representation in the error message. Displaying units in the

Re: An out-of-date comment in nodeIndexonlyscan.c

On 14/05/18 02:15, Thomas Munro wrote: Hello, Since commit cdf91edb (2012), nodeIndexonlyscan.c says: /* * Predicate locks for index-only scans must be acquired at the page * level when the heap is not accessed, since tuple-level predicate

Re: Incorrect comment in get_partition_dispatch_recurse

On 17 May 2018 at 02:51, Robert Haas wrote: > On Mon, May 14, 2018 at 12:57 AM, David Rowley > wrote: >> The "minus 1" part is incorrect. It simply just stores the 0-based >> index of the item in the list. I was going to fix it by removing

Re: Removing unneeded self joins

Hi, On 2018-05-16 12:26:48 -0400, Robert Haas wrote: > Also, I'm not sure that I believe that it's always easy to avoid > generating such queries. Yea. There's obviously plenty cases where ORMs just want to make the database hurt. But especially when building a join between a number of tables

Re: Removing unneeded self joins

Thomas Munro writes: > IIUC in DB2 (the clear winner at join elimination in the article you > mentioned), you get these sorts of things by default (optimisation > level 5 includes it), but not if you SET CURRENT QUERY OPTIMIZATION = > 3 as many articles recommend

Re: Removing unneeded self joins

On 17 May 2018 at 10:37, Tom Lane wrote: > Thomas Munro writes: >> IIUC in DB2 (the clear winner at join elimination in the article you >> mentioned), you get these sorts of things by default (optimisation >> level 5 includes it), but not if you

Re: Removing unneeded self joins

David Rowley writes: > On 17 May 2018 at 10:13, Tom Lane wrote: >> Yeah. It'd have to be a very heuristic thing that doesn't account >> for much beyond the number of relations in the query, and maybe their >> sizes --- although I don't think we

Re: Removing unneeded self joins

On 2018-05-16 18:37:11 -0400, Tom Lane wrote: > Thomas Munro writes: > > IIUC in DB2 (the clear winner at join elimination in the article you > > mentioned), you get these sorts of things by default (optimisation > > level 5 includes it), but not if you SET CURRENT

Re: Removing unneeded self joins

On 2018-05-16 18:55:41 -0400, Tom Lane wrote: > David Rowley writes: > > On 17 May 2018 at 10:13, Tom Lane wrote: > >> Yeah. It'd have to be a very heuristic thing that doesn't account > >> for much beyond the number of relations in the query,

Re: Postgres 11 release notes

On Wed, May 16, 2018 at 01:22:45PM +0900, Michael Paquier wrote: > On Mon, May 14, 2018 at 08:45:44PM -0400, Bruce Momjian wrote: > > What TLS does is to mix the offered ciphers into the negotiation hash so > > a man-in-the-middle can't pretend it doesn't support something. Could > > we do

Re: [HACKERS] Planning counters in pg_stat_statements

I am not actively working on this now, but I'll come back to it for PG12 if you or Lukas don't beat me to it, and I'll help/test/review if I you do. It seems there is plenty of demand for the feature and I'll be very happy to see it. Good to know, thanks! I'd argue that it might be better to

Re: Postgres 11 release notes

On Wed, May 16, 2018 at 08:59:23PM +0900, Michael Paquier wrote: > On Wed, May 16, 2018 at 01:09:07PM +0300, Heikki Linnakangas wrote: > > I have to agree with Bruce, that it's pretty useless to implement channel > > binding, if there is no way to require it in libpq. IMHO that must be > > fixed.

Re: Postgres 11 release notes

On Wed, May 16, 2018 at 10:08:18AM -0400, Alvaro Herrera wrote: > On 2018-May-15, Bruce Momjian wrote: > > > On Wed, May 16, 2018 at 09:01:35AM +0900, Tatsuo Ishii wrote: > > > There's a small typo. > > > > > > > Add support for with huge(large) pages on Windows (Takayuki Tsunakawa, > > > >

Re: Incorrect comment in get_partition_dispatch_recurse

On 17 May 2018 at 13:17, Amit Langote wrote: > Or maybe, change the comment to say that even the negative indexes are > 0-based like you pointed out, *but* instead of updating the comment like > you suggest above, change the other index value assignment statement to

Re: Postgres 11 release notes

On Thu, May 17, 2018 at 5:54 AM, Bruce Momjian wrote: > > Oh, sorry, changed to: > > Allow single-evaluation queries, e.g. WHERE > clause aggregate queries, and functions in the target list to be > parallelized (Amit Kapila, Robert Haas) > LGTM. Thanks.

Re: partition -> partitioned

On 17 May 2018 at 13:52, Amit Langote wrote: > Commit 499be013de6 used 'partition' where it really meant 'partitioned' in > a few places including in a variable name. For example, what almost all > places call 'partitioned_rels', make_partition_pruneinfo called >

Re: partition -> partitioned

On 2018/05/17 11:40, David Rowley wrote: > On 17 May 2018 at 13:52, Amit Langote wrote: >> Commit 499be013de6 used 'partition' where it really meant 'partitioned' in >> a few places including in a variable name. For example, what almost all >> places call

Re: Postgres 11 release notes

On Wed, May 16, 2018 at 09:55:05AM +0530, Amit Kapila wrote: > On Wed, May 16, 2018 at 12:17 AM, Bruce Momjian wrote: > > On Tue, May 15, 2018 at 08:45:07AM +0530, Amit Kapila wrote: > >> No, it is not like that. We divide the scan among workers and each > >> worker should

Re: Odd procedure resolution

On Wed, May 16, 2018 at 03:37:18PM -0400, Robert Haas wrote: > On Wed, May 16, 2018 at 3:29 PM, Tom Lane wrote: > > BTW, we seem to have some confusion here already: > > > > regression=# create function foo(int) returns int as 'select $1' language > > sql; > > CREATE FUNCTION

Re: Postgres 11 release notes

On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote: > SCRAM-with-binding is the first password method that attempts to avoid > man-in-the-middle attacks, and therefore is much less likely to be able > to trust what the endpoints supports. I think it is really the > channel_binding_mode

Re: Removing unneeded self joins

On 17 May 2018 at 10:55, Tom Lane wrote: > David Rowley writes: >> There's probably some argument for delaying obtaining the relation >> size until after join removal and probably partition pruning too, but >> it's currently done well before that

partition -> partitioned

Hi. Commit 499be013de6 used 'partition' where it really meant 'partitioned' in a few places including in a variable name. For example, what almost all places call 'partitioned_rels', make_partition_pruneinfo called 'partition_rels'. Attached a patch to make that uniform to avoid confusion.

Re: Removing unneeded self joins

David Rowley writes: > On 17 May 2018 at 11:00, Andres Freund wrote: >> Wonder if we shouldn't just cache an estimated relation size in the >> relcache entry till then. For planning purposes we don't need to be >> accurate, and usually activity

Re: Postgres 11 release notes

On Wed, May 16, 2018 at 01:50:04PM +0300, Heikki Linnakangas wrote: > >* Allow bytes to be specified for server variable sizes (Beena Emerson) > > > >The specification is "B". > > I had to dig the commit in the git history to figure out what this is. I'd > suggest rewording this: > > * Allow

Re: Postgres 11 release notes

On Thu, May 17, 2018 at 09:56:49AM +0900, Michael Paquier wrote: > On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote: > > SCRAM-with-binding is the first password method that attempts to avoid > > man-in-the-middle attacks, and therefore is much less likely to be able > > to trust what

Re: Incorrect comment in get_partition_dispatch_recurse

On 2018/05/17 3:28, David Rowley wrote: > On 17 May 2018 at 02:51, Robert Haas wrote: >> I think that's clearer. Committed with a few tweaks that are >> hopefully improvements. > > Thanks for committing. Although, I disagree with your tweak: > > +* 1-based index into

Re: Removing unneeded self joins

On 17 May 2018 at 11:00, Andres Freund wrote: > Wonder if we shouldn't just cache an estimated relation size in the > relcache entry till then. For planning purposes we don't need to be > accurate, and usually activity that drastically expands relation size > will trigger

Re: Removing unneeded self joins

On 2018-05-16 22:11:22 -0400, Tom Lane wrote: > David Rowley writes: > > On 17 May 2018 at 11:00, Andres Freund wrote: > >> Wonder if we shouldn't just cache an estimated relation size in the > >> relcache entry till then. For planning purposes

Re: Removing unneeded self joins

David, Many thanks for the detailed explanation. I'll try to code it up and measure how much overhead it introduces. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Memory unit GUC range checks

On Wed, May 16, 2018 at 10:41 PM, Andres Freund wrote: > On 2018-05-16 15:49:29 +0300, Heikki Linnakangas wrote: > > Here's a pretty straightforward fix for these two issues. Any objections > or > > better ideas? > > Generally ok, two minor points: > > > diff --git

Re: NaNs in numeric_power (was Re: Postgres 11 release notes)

On 16 May 2018 at 14:44, Tom Lane wrote: > Dean Rasheed writes: >> In the case 1 ^ NaN = 1, what should the result scale be? > > The result is exact, so I don't see a reason to be worried about its > scale. Messing with the scale would also require

Re: Removing unneeded self joins

On Thu, May 17, 2018 at 3:43 AM, Alexander Kuzmenkov wrote: > There is a join optimization we don't do -- removing inner join of a table > with itself on a unique column. Such joins are generated by various ORMs, so > from time to time our customers ask us to look into

Re: NaNs in numeric_power (was Re: Postgres 11 release notes)

On 16 May 2018 at 09:55, Tom Lane wrote: > David Rowley writes: >> On 16 May 2018 at 02:01, Tom Lane wrote: >>> I'm not particularly fussed about getting credit for that. However, >>> looking again at how that patch series

Re: Removing unneeded self joins

HI, On 2018-05-17 08:48:58 +1200, David Rowley wrote: > On 17 May 2018 at 08:44, Simon Riggs wrote: > > What I was advocating was an approach that varies according to the > > query cost, so we don't waste time trying to tune the heck out of OLTP > > queries, but for larger

Re: Removing unneeded self joins

David Rowley writes: > On 17 May 2018 at 08:44, Simon Riggs wrote: >> What I was advocating was an approach that varies according to the >> query cost, so we don't waste time trying to tune the heck out of OLTP >> queries, but for larger

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

On Wed, May 16, 2018 at 4:54 PM, Tom Lane wrote: > Alexander Korotkov writes: > > On Wed, May 16, 2018 at 1:41 AM, Tom Lane wrote: > >> Perhaps there is a case for adding an additional flag to allow > specifying > >> "I can't

Re: Removing unneeded self joins

On 17 May 2018 at 10:13, Tom Lane wrote: > Yeah. It'd have to be a very heuristic thing that doesn't account > for much beyond the number of relations in the query, and maybe their > sizes --- although I don't think we even know the latter at the > point where join removal

Re: Memory unit GUC range checks

Hi, On 2018-05-16 15:49:29 +0300, Heikki Linnakangas wrote: > Here's a pretty straightforward fix for these two issues. Any objections or > better ideas? Generally ok, two minor points: > diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c > index 7cd2d2d80e..93402030f7

Re: Removing unneeded self joins

Simon Riggs writes: > What I would add is that I've seen cases where the extra joins do NOT > hurt performance, so the extra CPU used to remove the join hurts more > than the benefit of removing it. Yes, we tried it. Interesting. The concern I had was more about the cost

Re: Removing unneeded self joins

On 16 May 2018 at 15:10, Tom Lane wrote: > Simon Riggs writes: >> What I would add is that I've seen cases where the extra joins do NOT >> hurt performance, so the extra CPU used to remove the join hurts more >> than the benefit of removing it. Yes, we

Re: [PROPOSAL] Shared Ispell dictionaries

On Wed, May 16, 2018 at 09:33:46AM -0400, Robert Haas wrote: > > In sum, I think the problem is mostly solved. Backend 2 unpins the > > segment in next ts_lexize() call. But if backend 2 doesn't call > > ts_lexize() (or other TS function) anymore the segment will remain mapped. > > It is the only

Re: Odd procedure resolution

On Fri, Mar 23, 2018 at 10:42 AM, Ashutosh Bapat wrote: > On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane wrote: >> Ashutosh Bapat writes: >>> Incidently the fix looks quite simple. See patch attached. >> >> ISTM

Re: Odd procedure resolution

Robert Haas writes: > On Fri, Mar 23, 2018 at 10:42 AM, Ashutosh Bapat > wrote: >> On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane wrote: >>> ISTM this patch effectively proposes to make procedures have their own >>>

Re: Removing unneeded self joins

On 17 May 2018 at 03:43, Alexander Kuzmenkov wrote: > I'd be glad to hear your thoughts on this. (I only glanced at the patch) I've thought and discussed this before on this list. I think the arguments for and against it were much the same as you've received already.

Re: Odd procedure resolution

On Wed, May 16, 2018 at 3:29 PM, Tom Lane wrote: > My opinion remains unchanged. If you're unhappy about the system > confusing procedure foo(int) and function foo(real), maybe the answer > is to not overload the name "foo" with such enthusiasm. But putting > kluges into

Re: Removing unneeded self joins

On 16 May 2018 at 11:26, Robert Haas wrote: > On Wed, May 16, 2018 at 12:08 PM, Tom Lane wrote: >> Alexander Kuzmenkov writes: >>> There is a join optimization we don't do -- removing inner join of a >>> table with itself on

Re: Removing unneeded self joins

On 17 May 2018 at 08:44, Simon Riggs wrote: > What I was advocating was an approach that varies according to the > query cost, so we don't waste time trying to tune the heck out of OLTP > queries, but for larger queries we might take a more considered > approach. That's

Re: Incorrect comment in get_partition_dispatch_recurse

On Wed, May 16, 2018 at 2:28 PM, David Rowley wrote: > Thanks for committing. Although, I disagree with your tweak: > > +* 1-based index into the *pds list. > > I think that's making the same mistake as the last comment did. You > think it's 1-based because the

Re: Removing unneeded self joins

> On May 16, 2018, at 1:58 PM, Andres Freund wrote: > > Hi, > > On 2018-05-16 12:26:48 -0400, Robert Haas wrote: >> Also, I'm not sure that I believe that it's always easy to avoid >> generating such queries. > > Yea. There's obviously plenty cases where ORMs just want to

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

On 17 May 2018 at 01:19, Robert Haas wrote: > Hmm, that's actually not as bad as I thought. Thanks for the > explanation. I think if I were going to try to improve things, I'd > try to annotate the Append node with the name of the partitioned table > that it's using for

Re: GiST VACUUM

On Wed, Mar 7, 2018 at 7:50 PM, Andrey Borodin wrote: > Here's new version of GiST VACUUM patch set aimed at CF 2018-09. Hi Andrey, FYI Windows doesn't like this patch[1]. + uint16_t flags; I think that needs to be uint16? [1]

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

On 2018/05/17 12:30, Etsuro Fujita wrote: > (2018/05/17 1:16), Robert Haas wrote: >> Was it just good luck that this ever worked at all?  I mean: >> >> -    if (rti<  root->simple_rel_array_size&& >> -    root->simple_rel_array[rti] != NULL) >> +    if (rti< 

Re: Needless additional partition check in INSERT?

On 2018/05/17 14:15, David Rowley wrote: > On 10 May 2018 at 21: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

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

On 2018/05/17 14:19, Amit Langote wrote: > Looking at this for a bit, I wondered if this crash wouldn't have occurred > if the "propagation" had also considered join relations in addition to > simple relations. For example, if I changed inheritance_planner like the > attached (not proposing that

Re: Oddity in COPY FROM handling of check constraints on partition tables

(2018/05/17 0:27), Robert Haas wrote: On Tue, Mar 27, 2018 at 9:00 AM, Etsuro Fujita wrote: Attached is a patch for fixing this issue. This no longer applies. The patch has already been committed by you [1]. Thanks for committing! Best regards, Etsuro Fujita

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

(2018/05/17 1:16), Robert Haas wrote: On Fri, May 11, 2018 at 8:46 AM, Etsuro Fujita wrote: I added an assertion test to make_modifytable to match that in create_modifytable_path. Attached is an updated version of the patch. Committed. Thanks you! Was it

  1   2   >