Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

eventing them from relying on options that may go away is not a goal at all, since barring the ability to predict the future, it's impossible anyway. If it's possible to prevent to write a precisely-targeted check that rules out only actually-meaningless collations and nothing else, I'm fine with that. --

Re: [HACKERS] What's with all the fflush(stderr) calls in pg_standby.c?

to do anything about that. Still, I'd be against spending a lot of time trying to improve a tool that has mostly outlived its usefulness - we ought to be trying to enhance the in-core facilities instead. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

x our bugs; now, we think we have infinite latitude to classify anything we don't like as a bug. Neither of those ideas is good software engineering. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

hat's kinda the point -- so there's no need for it to carry that information, or to add any new nodes. At least, IIUC. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] 10RC1 crash testing MultiXact oddity

tion is whether it also shows up if you initdb with 9.4.latest and then run the same test. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

. I might be missing something, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] "inconsistent page found" with checksum and wal_consistency_checking enabled

ther than later, but there's nothing particularly serious or urgent about this bug as compared to any other one. I've committed the proposed patch to master and REL_10_STABLE. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mai

Re: [HACKERS] Page Scan Mode in Hash Index

ently and cause us to skip cleanup that we could usefully have done. So I propose the attached hashscan-no-lsn.patch as an alternative. Thoughts? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company hash-cleanup-changes.patch Description: Binary data has

Re: [HACKERS] close_ps, NULLs, and DirectFunctionCall

to agree, although I'm not really familiar with this area. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 10RC1 crash testing MultiXact oddity

y understand. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Improve catcache/syscache performance.

On Fri, Sep 22, 2017 at 2:15 AM, Andres Freund <and...@anarazel.de> wrote: > This results in making cache lookups themselves roughly three times as > fast - full-system benchmarks obviously improve less than that. Wow. That's really good. -- Robert Haas Enterp

Re: [HACKERS] hash index on unlogged tables doesn't behave as expected

hings in stable branches that would be better left alone. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] hash index on unlogged tables doesn't behave as expected

On Sep 21, 2017, at 8:59 AM, Amit Kapila wrote:. > I think giving an error message like "hash indexes are not WAL-logged > and .." for unlogged tables doesn't seem like a good behavior. +1. This seems like deliberate behavior, not a bug. ...Robert -- Sent via

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

will > simplify the code. I haven't done that change in this patchset. I was > busy debugging the Q7 regression. Let me know your comments about > that. Hmm, I'm not sure that's the best approach, but let me look at it more carefully before I express a firm opinion. -- Robert Haas Enter

Re: [HACKERS] Page Scan Mode in Hash Index

s. logged differences, and the header comment for hashbucketcleanup still says that scans depend on increasing-TID order (really, 0001 should change that text somehow). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing li

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

rits_fn.h was unneeded. I rewrote a lot of the comments and made some other style tweaks. Don't look now, but I think it might be about time for the main act. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsq

Re: [HACKERS] POC: Cache data in GetSnapshotData()

same sort of thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] POC: Cache data in GetSnapshotData()

ine) we can see > improvements. OK, makes sense. So for whatever reason, this appears to be something that will only help users with >2 sockets. But that's not necessarily a bad thing. The small regression at 1 client is a bit concerning though. -- Robert Haas EnterpriseDB: http://www.enterprise

Re: [HACKERS] POC: Cache data in GetSnapshotData()

494336.282804 691614.00046339.9075941867 Oh, you're right. I was confused. But now I'm confused about something else: if you're seeing a clear gain at higher-client counts, why is Jesper Pederson not seeing the same thing? Do you have results for a 2-socket machine? Maybe this only help

Re: [HACKERS] POC: Cache data in GetSnapshotData()

reported a 39% speedup at 256 clients. Is that really correct? There's basically no improvement up to threads = 2 x CPU cores, and then after that it starts to improve rapidly? What happens at intermediate points, like 160, 192, 224 clients? -- Robert Haas EnterpriseDB: http://www.enterprisedb

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

nd then perform separate joins on each partition. The above plan is clearly better than what we can do today, where every worker would have to repeat the sort, ugh, but I don't know if it's the best plan. Fortunately, to get this patch committed, we don't have to figure that out. --

Re: [HACKERS] Page Scan Mode in Hash Index

reset currPage or lsn, because we expect _hash_kill_items to be called for the old page after this function returns.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to y

Re: [HACKERS] Re: [COMMITTERS] pgsql: Expand partitioned table RTEs level by level, without flattening

s as well. I have removed the > assertion and instead fixed the code to skip anything which is not > "base" or "other member rel". > > I have also added a test to cover dead relations and lateral > references in join.sql. Committed. Thanks. -- Robert Haas Ente

Re: [HACKERS] SCRAM in the PG 10 release notes

ternative. But let's not. Let's just do what we're already doing - tell people what we've got and let them decide whether to use it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

Re: [HACKERS] Page Scan Mode in Hash Index

a problem because of the LSN check. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Error: dsa_area could not attach to a segment that has been freed

On Wed, Sep 20, 2017 at 5:54 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: > By the way, dsa.c really needs a cross-reference to shm_toc.c and vice > versa. With a hint as to when each is appropriate. /me blinks. Aren't those almost-entirely-unrelated facilities? -- Robert Haas

Re: [HACKERS] [COMMITTERS] pgsql: Make WAL segment size configurable at initdb time.

when the server is too old to tell us the real answer, whereas before, we assumed it always. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Page Scan Mode in Hash Index

vacuum allows heap TIDs to be reused. To reuse a heap TID, we have to know that there are no index entries pointing to it. There's no way for the heap to know that a page-at-a-time index vacuum has even happened, let alone which TIDs were affected and that all other indexes have also removed all index

Re: [HACKERS] Page Scan Mode in Hash Index

e such an operation doesn't allow TIDs to be reused. Did I get it right? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Boom filters for hash joins (was: A design for amcheck heapam verification)

way to avoid doing it when it didn't help. That may or may not be why you didn't pursue it, but I'm fairly sure it was my motivation for being unexcited about the whole idea. I think if we can solve that problem somehow, we have a winner. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The En

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

INTO x, y, z and wants some of a-k to go into x, some more to go into y, and some more to go into z (and heaven help you if you drop a column from x or y -- now the whole semantics of the query change, yikes). What's reasonable is to write SELECT a, b, c INTO x, y, z and have those correspond 1:1. -

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

kes more sense to try to apply that option to new behaviors we want to control than to invent some new system. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to yo

Re: [HACKERS] UPDATE of partition key

e constraints for this patch should be too tight, because we're talking about being able to do something vs. not being able to do it at all, but we should try to have it not stink. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-ha

Re: [HACKERS] Re: [COMMITTERS] pgsql: Perform only one ReadControlFile() during startup.

On Tue, Sep 19, 2017 at 12:51 PM, Andres Freund <and...@anarazel.de> wrote: > That'd not be that a crazy amount of > shared memory that'd need to be touched in shared memory, ... You mean, in the postmaster? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterpris

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

function scope. I'm not getting your point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Page Scan Mode in Hash Index

at they're unnecessary is that there's no code below that in the loop anyway, so the loop is already going to go back around to the top. Whether to change this is a matter of style, so I won't complain too much if you want to leave it the way it is, but personally I'd favor removing them. --

Re: [HACKERS] src/test/subscription/t/005_encoding.pl is broken

wal" onto disk. Huh? Decoding and applying the changes has to take some finite time greater than 0. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes t

Re: [HACKERS] Re: [COMMITTERS] pgsql: Perform only one ReadControlFile() during startup.

On Mon, Sep 18, 2017 at 2:04 PM, Andres Freund <and...@anarazel.de> wrote: > On 2017-09-18 12:16:42 -0400, Robert Haas wrote: >> On Mon, Sep 18, 2017 at 6:32 AM, Andres Freund <and...@anarazel.de> wrote: >> > One thing that I've noticed for a while, but that I was r

Re: [HACKERS] Boom filters for hash joins (was: A design for amcheck heapam verification)

On Mon, Sep 18, 2017 at 5:13 PM, Peter Geoghegan <p...@bowt.ie> wrote: > On Mon, Sep 18, 2017 at 2:07 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Mon, Sep 18, 2017 at 1:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Uh, why does the planner need

Re: [HACKERS] Boom filters for hash joins (was: A design for amcheck heapam verification)

ey on a.x referencing b(x). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

; RTE_JOIN is created only for joins specified using JOIN clause i.e > syntactic joins. The joins created during query planner like rel1, > rel2, rel3 do not have RTE_JOIN. So, we can't use RTE_JOIN there. OK, never mind that then. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Parallel Hash take II

an executor-specific rule, not necessarily a general rule to which other users of parallelism must adhere; they can choose their own strategies. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] Boom filters for hash joins (was: A design for amcheck heapam verification)

oins). Presumably some other method needs to be found, but I'm not clear what that other method is. Our planner is fundamentally bottom-up, and it's not at all clear how to make it capable of changing its mind later about something like the number of rows that a scan of A will return, or how much that sca

Re: [HACKERS] Re: [COMMITTERS] pgsql: Perform only one ReadControlFile() during startup.

that session. I > don't recall that frequently happening, but these days it happens nearly > every time. I don't understand what you're talking about here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailin

Re: [HACKERS] Reporting query on crash even if completed

nother case for a backend that crashed without ever running a query. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

On Mon, Sep 18, 2017 at 7:17 AM, Andres Freund <and...@anarazel.de> wrote: > Private: Not so much. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make change

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

me direction with this, committed the patch for that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

e a lot of backpatch pain. I tend to agree with you, but it's not a huge deal either way. Even if somebody fails to update third-party code that touches this, a lot of times it'll work anyway. But that very fact is, of course, why it would be slightly better to break it explicitly. -- Robert Ha

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

tcases-for-partition-wise-join-NOT-FOR-COMM.patch? What code, if any, is not covered by either of those test suites? Could we do meaningful testing of this with something like Andreas Seltenreich's sqlsmith? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Com

Re: [HACKERS] path toward faster partition pruning

h > series that Ashutosh Bapat posted yesterday [1]. It doesn't merely overlap; it's obviously a derivative work, and the commit message in your version should credit all the authors. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] SQL/JSON in PostgreSQL

"major" rebase and hasn't been updated in a month, and given that the CF is already half over, this should just be bumped to the next CF. We're supposed to be trying to review things that were ready to go by the start of the CF, not the end. -- Robert Haas EnterpriseDB: http://www.enterp

Re: [HACKERS] Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

h it's a bit marginal given the stature of the opponents. I'm still not going to change this just before rc1 wraps though. I think it has to wait for 11. There's too much chance of collateral damage. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Se

Re: [HACKERS] Optimise default partition scanning while adding new partition

cross the board. I believe the intended advantage of the current system is that if you specify multiple operations in a single ALTER TABLE command, you only do one scan rather than having a second scan per operation. If that's currently working, we probably don't want to make it stop working. -- Rob

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

m not so sure about this part. Why don't we want to let users control this? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Process startup infrastructure is a mess

it apart from feeling good about having done it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Improve geometric types

ink such a comment has much value, but I am not going to spend a lot of time arguing about it. It's really up to the eventual committer to decide, and that probably won't be me in this case. My knowledge of the geometric types isn't great, and I am a tad busy breaking^Wimproving things I do under

Re: [HACKERS] postgres_fdw: evaluate placeholdervars on remote server

CF is of course to be expected, but we don't even really have enough bandwidth to deal with the patches that are being timely updated, never mind the ones that aren't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

* multi-byte character from it's first byte (not the case for client its this is not the case + * encodings, see GB18030). As st_activity always is stored using server is always stored using a server + * pgstat_clip_activity() to trunctae correctly. truncate -- Robert Haas Enterp

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

On Thu, Sep 14, 2017 at 8:30 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > LGTM. The patch applies cleanly on the current HEAD, compiles (small > bit in regress.c requires compilation), and make check passes. Marking > this as "ready for committer". Co

Re: [HACKERS] Warnings "unrecognized node type" for some DDLs with log_statement = 'ddl'

k into the list > given in 'nodes.h' file but couldn't find any missing nodes. So, yes, > your patch does solve the problem completely and looks good to me. > Thanks. Committed and back-patched. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --

Re: [HACKERS] [PATCH] Improve geometric types

nk we can count on PostgreSQL developers to understand the advantages of an inline function over a macro. Even if they don't, the solution can't be to put a comment in every place where an inline function is used explaining it. That would be very repetitive. -- Robert Haas Ent

[HACKERS] Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

thing? Because we do not have consensus on changing it. I've decided that you're right, but several other people are saying "no". I can't just go change it in the face of objections. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

ght back to Needs Review. But if things are only being auto-flipped in one direction that's going to get tedious. Or one could imagine having the CF app show the CI status alongside the existing status column. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --

Re: [HACKERS] postgres_fdw super user checks

lunky and annoying way of trying to make this work, no matter which of those use cases you happen to have. But I'm not exactly sure what would be better, either, and like you say, it's a bit late to be breaking compatibility at this point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.

Re: [HACKERS] [POC] hash partitioning

w.postgresql.org/message-id/579077fd-8f07-aff7-39bc-b92c855cdb70%40redhat.com Yeah, no issues. I knew about the dependency between those patches, but I'm pretty sure there wasn't any terribly explicit discussion about it, even if the issue probably came up parenthetically someplace or other.

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

hew, getting that sorted out has been an astonishing amount of work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/ma

Re: [HACKERS] [POC] hash partitioning

about this, just raising a concern, and I'm not trying to beat you up either, just let you know that it is definitely on the radar screen but not there yet. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsq

Re: [HACKERS] [POC] hash partitioning

bout an hour after this goes in. But probably we can do better in core easily enough. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postg

Re: [HACKERS] Log LDAP "diagnostic messages"?

Improved code coverage is becoming a fad. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] expanding inheritance in partition bound order

map = convert_tuples_by_name(RelationGetDescr(parent), > tupdesc, > gettext_noop("could not convert row type")); > > > > Other than that, the patch looks good to me. I verified that the leaf > oids are ordered exaclty in the order of the UPDATE subplan

Re: [HACKERS] Parallel Append implementation

picks a non-partial path, though, the workers are locked out of that path, because a single process must run it all the way through. So the leader should avoid choosing a non-partial path unless there are no partial paths remaining. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com Th

Re: [HACKERS] [POC] hash partitioning

pefully this patch has been updated to use a seed (I haven't looked yet). And there was a concern about hash functions not being portable, but the conclusion of that was basically that most people think --load-via-partition-root will be a satisfactory workaround for cases where that becomes a problem

Re: [HACKERS] Optimise default partition scanning while adding new partition

ist_parted2_def_p2 has Check constraints: "check_a" CHECK (a = ANY (ARRAY[31, 32])) Well, if a is 21 or 22 for the first, or 31 or 32 for the second, then it's not 7. Or so I would think. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Compan

Re: [HACKERS] Is it time to kill support for very old servers?

he time has come to kill v2 with fire, but doing the things that have been done first has got to be a good idea either way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()

n sort that out? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

be we shouldn't either. So >> I'll hold my nose and change my vote to canonicalizing rather than >> rejecting outright. > > I vote for rejecting it. DDL compatibility is less valuable than other > compatibility. The hypothetical affected application can change its DDL to > p

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

oned tables) will change that, but even > then we won't need sub-query's own PartitioendChildRelInfo. OK, let's assume you're correct unless some contrary evidence emerges. Committed without that part; thanks for the review. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterpri

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

ct, but I wonder if we can think that will really fix the bug completely, or more generally if it will fix all of the bugs that come from ALTER TABLE .. NO INHERIT not locking the parent. I have a sneaking suspicion that may be wishful thinking. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] generated columns

ns will have to be careful to always specify one or the other, because they don't know what the default will be on the system where it's deployed. Similarly for an author of a portable application. I think it'll create fewer headaches if we just pick a default and stick with it. -- Robert Haas Enterp

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

need everything associated with the top-parent. That doesn't seem like a problem to me, but it's something to note. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company mechanical-partrels-fix.patch Description: Binary data pcinfo-for-subquery.patch Desc

Re: [HACKERS] expanding inheritance in partition bound order

The value multiplied back by -1 is returned as the multiplied by -1, not multiplied back by -1 + * tables in the tree, using which, search is continued further down the + * partition tree. Period after "in the tree". Then continue: "This value is used to continue the search

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

> Oracle, or "show create table" in MySQL. OK, thanks. I still don't really like allowing this, but I can see that compatibility with other systems has some value here, and if nobody else is rejecting these cases, maybe we shouldn't either. So I'll hold my nose and change my

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

nicalizing stored values, > instead of erroring out. Please see attached if that's what you were > thinking too. Coincidentally, I wrote a patch for this too, but mine goes back to rejecting MINVALUE or MAXVALUE followed by anything else. -- Robert Haas EnterpriseDB: http://www.enterprisedb

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

> > So thinking about this afresh, my preference would actually be to just > canonicalise the values stored rather than erroring out. Can you be more specific about what other databases do here? Which other systems support MINVALUE/MAXVALUE, and what are their respective behaviors in this sit

Re: [HACKERS] domain type smashing is expensive

still need the tlists for other reasons, so plans would get bigger. But I don't think that's a huge problem if it makes them run faster. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] psql - add special variable to reflect the last query status

acing a constant string that we've had for ~15 years with a different constraint string isn't doing anything about the lack-of-information problem you're complaining about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

ifying. > > I'm afraid many will still re-create standbys from scratch without a really > good and complete example to follow. And I'm afraid that they won't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mai

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

uch as possible. If we want to get rid of the locking in the executor altogether, that's a separate discussion where, I have a feeling, there will prove to be better reasons for the way things are than we are right now supposing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] psql - add special variable to reflect the last query status

versally returning the empty string to justify the risk of application breakage. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.

Re: [HACKERS] domain type smashing is expensive

On Tue, Sep 12, 2017 at 1:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On short-running queries that return a lot of columns, >> SendRowDescriptionMessage's calls to getBaseTypeAndTypmod() are a >> noticeable expense.

[HACKERS] domain type smashing is expensive

t of prepared statements is supposed to be to do as much of the work as possible at prepare time so that bind/execute is as fast as possible, but we're not really adhering to that design philosophy here. However, I don't have a clear idea of exactly how to do that. Thoughts? -- Robert Haas Enter

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

dering. Your idea is probably a lot simpler to implement, though, and I definitely agree that shifting the work from the write side to the read side makes sense. Updating pg_stat_activity is a lot more common than reading it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Pos

Re: [HACKERS] Constraint exclusion for partitioned tables

rent when it doesn't help? In that case we will have some loss. I'm inclined to think that's OK, but it's something to think about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

On Mon, Sep 11, 2017 at 6:41 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Mon, Sep 11, 2017 at 11:43 PM, Robert Haas <robertmh...@gmail.com> wrote: >> So I think this is just an excuse for turning --no-security-labels >> into --no-object-property=security

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > Robert Haas wrote: >> I just don't understand why you think there should be multiple >> spellings of the same bound. Generally, canonicalization is good. >> One of my fears here i

Re: [HACKERS] The case for removing replacement selection sort

it was pretty easy to find cases where lowering work_mem made sorting ordered data go faster. But I could easily be wrong. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make c

Re: [HACKERS] The case for removing replacement selection sort

e heap is also bigger, which hurts. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

individual kind of object doesn't have many more properties than what we already handle. So I think this is just an excuse for turning --no-security-labels into --no-object-property=security-label. To me, that's just plain worse. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The

Re: [HACKERS] CLUSTER command progress monitor

at are known to be accurate, because users hate (and mock) >> inaccurate progress reports. > > Do you mean to use the number of rows by using below calculation instead > OldHeap->rd_rel->reltuples? > > estimate rows = physical table size / average row length No, I mean don't

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

behavior will be correct in all cases. I haven't had time to look at Amit's comments in detail yet so I don't know whether I agree with his analysis or not, but we have to look at what's going on under the hood to know whether the engine is working -- not just listen to the noise it makes. -- Ro

<    1   2   3   4   5   6   7   8   9   10   >