Re: [HACKERS] [POC] hash partitioning

On 2017/09/27 22:41, Jesper Pedersen wrote: > On 09/27/2017 03:05 AM, amul sul wrote: Attached rebased patch, thanks. >>> While reading through the patch I thought it would be better to keep >>> MODULUS and REMAINDER in caps, if CREATE TABLE was in caps too in order to >>> highlight

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On Fri, Sep 22, 2017 at 03:13:10PM -0400, Tom Lane wrote: > Somebody inserted this into vacuum.c's get_rel_oids(): > > tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid)); > if (!HeapTupleIsValid(tuple)) > elog(ERROR, "cache lookup failed for relation %u", relid);

Re: [HACKERS] pgbench - minor fix for meta command only scripts

On Tue, Sep 12, 2017 at 03:27:13AM +0200, Fabien COELHO wrote: > >Shouldn't we use pg_usleep to ensure portability? it is defined for > >front-end code. But it returns void, so the error check will have to be > >changed. > > Attached v3 with pg_usleep called instead. > > >I didn't see the

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

On Thu, Sep 28, 2017 at 1:31 PM, Andres Freund wrote: > On September 27, 2017 9:06:49 PM PDT, Andres Freund > wrote: >>On 2017-09-28 00:01:53 -0400, Tom Lane wrote: >>> Could we please not perpetuate the brain-dead "s" and "l" suffixes >>> on these names?

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Thu, Sep 28, 2017 at 1:20 AM, Bossart, Nathan wrote: > On 9/26/17, 1:38 PM, "Bossart, Nathan" wrote: >> On 9/25/17, 12:42 AM, "Michael Paquier" wrote: >>> + if (!IsAutoVacuumWorkerProcess()) >>> +

Re: [HACKERS] Use of RangeVar for partitioned tables in autovacuum

On Wed, Sep 27, 2017 at 11:28 AM, Michael Paquier wrote: > In conclusion, I think that the open item of $subject should be > removed from the list, and we should try to get the multi-VACUUM patch > in to cover any future problems. I'll do so if there are no >

Re: [HACKERS] path toward faster partition pruning

On Wed, Sep 27, 2017 at 6:52 AM, Amit Langote wrote: I was looking into the latest patch set, seems like we can reuse some more code between this path and runtime pruning[1] + foreach(lc1, matchedclauses[i]) + { + Expr *clause = lfirst(lc1); + Const *rightop =

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

On September 27, 2017 9:06:49 PM PDT, Andres Freund wrote: >On 2017-09-28 00:01:53 -0400, Tom Lane wrote: >> Andres Freund writes: >> > Attached is an extension of the already existing pg_bswap.h that >> > a) adds 16 bit support >> > b) moves everything

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

On 2017-09-28 00:01:53 -0400, Tom Lane wrote: > Andres Freund writes: > > Attached is an extension of the already existing pg_bswap.h that > > a) adds 16 bit support > > b) moves everything to inline functions, removing multiple evaluation > >hazards that were present

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

Andres Freund writes: > Attached is an extension of the already existing pg_bswap.h that > a) adds 16 bit support > b) moves everything to inline functions, removing multiple evaluation >hazards that were present everywhere. > c) adds pg_nto{s,l,ll} and pg_hton{s,l,ll}

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Wed, Sep 27, 2017 at 4:05 PM, Ashutosh Bapat wrote: > On Wed, Sep 27, 2017 at 12:11 PM, Masahiko Sawada > wrote: >> On Tue, Sep 26, 2017 at 9:50 PM, Robert Haas wrote: >>> On Tue, Sep 26, 2017 at 5:06 AM,

[HACKERS] Early-adopter report for macOS 10.13

I mentioned last week that updating to Xcode 9.0 while still on macOS Sierra wasn't such a hot idea. I've now updated longfin's host to macOS High Sierra, and that fixed the little problem with a missing library dependency ... but all is not entirely well, because the new version of Xcode command

Re: [HACKERS] Arrays of domains

On 08/11/2017 01:17 PM, Tom Lane wrote: > I wrote: >> Probably a better answer is to start supporting arrays over domain >> types. That was left unimplemented in the original domains patch, >> but AFAICS not for any better reason than lack of round tuits. > Attached is a patch series that

Re: [HACKERS] list of credits for release notes

On Thu, Sep 28, 2017 at 9:11 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut >> At the PGCon Developer Meeting it was agreed[0] to add a list of credits >> to the

Re: [HACKERS] list of credits for release notes

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut > At the PGCon Developer Meeting it was agreed[0] to add a list of credits > to the release notes, including everyone who was mentioned in a commit > message. I have now completed

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

On Thu, Sep 28, 2017 at 2:20 AM, Andres Freund wrote: > This'll allow the later patches to allow the compiler to perform the > relevant optimizations. It also allows to optimize e.g. pq_sendint64() > to avoid having to do multiple byteswaps. I guess that you could clean up

Re: [HACKERS] Enhancements to passwordcheck

On Thu, Sep 28, 2017 at 12:06 AM, Alvaro Herrera wrote: > I think a password strength check must live at the end that does the > encryption -- something like in psql when you do the \password command, > *before* the encrypted password is sent to the server. Then you can

Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

> On 31 Aug 2017, at 21:49, Peter Eisentraut > wrote: > > On 5/30/17 23:10, Peter Eisentraut wrote: >> Here is a proposed solution that splits bgw_name into bgw_type and >> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. >> Uses of

Re: [HACKERS] Multicolumn hash indexes

On 09/27/2017 05:57 PM, Tom Lane wrote: If we follow GIST's lead that the leading column is "most important", the idea could be to require a search constraint on the first column, which produces the hash that determines the bucket assignment. Hashes for additional columns would just be payload

Re: [HACKERS] Multicolumn hash indexes

On Wed, Sep 27, 2017 at 11:57:23AM -0400, Tom Lane wrote: > Robert Haas writes: > > On Wed, Sep 27, 2017 at 9:56 AM, Jesper Pedersen > > wrote: > >> Maybe an initial proof-of-concept could store the hash of the first column > >> (col1) plus the

Re: [HACKERS] Use of RangeVar for partitioned tables in autovacuum

On Thu, Sep 28, 2017 at 3:11 AM, Bossart, Nathan wrote: > On 9/26/17, 9:28 PM, "Michael Paquier" wrote: >> In conclusion, I think that the open item of $subject should be >> removed from the list, and we should try to get the multi-VACUUM patch >>

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

Hi! On Wed, Aug 9, 2017 at 6:30 PM, Shubham Barai wrote: > Please find the updated patch for predicate locking in gin index here. > > There was a small issue in the previous patch. I didn't consider the case > where only root page exists in the tree, and there is a

Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hi 2017-09-25 13:25 GMT+02:00 Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp>: > Hello, this patch have been ignored for a long time since its proposal... > > At Sat, 11 Mar 2017 20:44:31 +0100, Pavel Stehule > wrote in

Re: [HACKERS] 200 = 199 + 1?

On Wed, Sep 27, 2017 at 5:45 PM, Tom Lane wrote: > Marko Tiikkaja writes: > > I wonder if the nested loop shouldn't have some kind of a cap on its own > > estimate if it's wildly off of what you'd get by multiplying the child > > nodes' estimates with each

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

Andres Freund writes: > On 2017-09-27 15:06:15 -0400, Tom Lane wrote: >> Yeah, constructing an index table of that sort on top of the existing >> FmgrBuiltin array could be done cheaply enough at startup. It irks me >> slightly that it's not part of the read-only text

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On 2017-09-27 15:30:45 -0400, Robert Haas wrote: > On Wed, Sep 27, 2017 at 1:40 PM, Andres Freund wrote: > > I don't think you can even measure the overhead of building the > > table. This is inserting ~8k rows in an accurately sized hashtable - a > > vanishingly small amount

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On Wed, Sep 27, 2017 at 1:40 PM, Andres Freund wrote: > I don't think you can even measure the overhead of building the > table. This is inserting ~8k rows in an accurately sized hashtable - a > vanishingly small amount of time in comparison to the backend startup > time (and

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

Hi, On 2017-09-27 15:06:15 -0400, Tom Lane wrote: > Yeah, constructing an index table of that sort on top of the existing > FmgrBuiltin array could be done cheaply enough at startup. It irks me > slightly that it's not part of the read-only text segment, but I can't > say that there's any really

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

Andres Freund writes: > On 2017-09-27 14:58:36 -0400, Tom Lane wrote: >> Yeah, I'd been kind of wondering about that approach too. We could have, >> say, a table of int16s indexed by OIDs from 0 to , containing zero or >> an index into the table of FmgrBuiltin structs.

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On 2017-09-27 14:58:36 -0400, Tom Lane wrote: > Andres Freund writes: > > Honestly before going there I'd rather just have > > an oid indexed array, computed at compile time. > > Yeah, I'd been kind of wondering about that approach too. We could have, > say, a table of

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

Andres Freund writes: > Honestly before going there I'd rather just have > an oid indexed array, computed at compile time. Yeah, I'd been kind of wondering about that approach too. We could have, say, a table of int16s indexed by OIDs from 0 to , containing zero or an

Re: [HACKERS] list of credits for release notes

Hi, On 2017-09-27 14:47:45 -0400, Peter Eisentraut wrote: > At the PGCon Developer Meeting it was agreed[0] to add a list of credits > to the release notes, including everyone who was mentioned in a commit > message. I have now completed that list. Nice! > For the following mentions I could

Re: [HACKERS] list of credits for release notes

> On 27 Sep 2017, at 19:47, Peter Eisentraut > wrote: > > At the PGCon Developer Meeting it was agreed[0] to add a list of credits > to the release notes, including everyone who was mentioned in a commit > message. I have now completed that list. Wow, it’s

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

Andrew Dunstan writes: > At this stage on reflection I agree it should be pulled :-( That seems to be the consensus, so I'll go make it happen. > I'm not happy about the idea of marking an input function as not > parallel safe, certainly not without a good deal

[HACKERS] list of credits for release notes

At the PGCon Developer Meeting it was agreed[0] to add a list of credits to the release notes, including everyone who was mentioned in a commit message. I have now completed that list. Attached is the proposed documentation commit as well as the raw list. Thoughts on the heading? I have

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On 2017-09-27 14:40:20 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-09-27 13:46:50 -0400, Tom Lane wrote: > >> The other question that ought to be answered is whether a gperf hash > >> table would be faster. > > > Ugh, hacking together a quick input file for

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

Andres Freund writes: > On 2017-09-27 13:46:50 -0400, Tom Lane wrote: >> The other question that ought to be answered is whether a gperf hash >> table would be faster. > Ugh, hacking together a quick input file for gperf, I'm *far* from > convinced. The generated code does

Re: [HACKERS] A design for amcheck heapam verification

On Wed, Sep 27, 2017 at 1:45 AM, Michael Paquier wrote: > I have signed up as a reviewer of this patch, and I have looked at the > bloom filter implementation for now. This is the kind of facility that > people have asked for on this list for many years. > > One first

Re: [HACKERS] Use of RangeVar for partitioned tables in autovacuum

On 9/26/17, 9:28 PM, "Michael Paquier" wrote: > In conclusion, I think that the open item of $subject should be > removed from the list, and we should try to get the multi-VACUUM patch > in to cover any future problems. I'll do so if there are no > objections. If

Re: [HACKERS] WIP: Separate log file for extension

Magnus Hagander wrote: > > On Fri, Aug 25, 2017 at 12:12 AM, Antonin Houska wrote: > > I like this idea in general. > > Then it's supposed to change some of its attributes > > > adjust_log_stream_attr(>filename, "my_extension.log"); > > This,

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

Andres Freund writes: > On 2017-09-27 11:50:56 -0400, Tom Lane wrote: >> Robert Haas writes: >>> I suppose an even better approach would be to build a perfect hash >>> table at compile time so that nothing needs to be built at run-time at >>> all, but

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On 2017-09-27 13:28:22 -0400, Robert Haas wrote: > On Wed, Sep 27, 2017 at 1:00 PM, Andres Freund wrote: > > We could relatively easily move it to be once-per-postmaster start for > > !EXEC_BACKEND builds. Constantly doing expensive binary searches is also > > pretty brute

Re: [HACKERS] WIP: Separate log file for extension

Tomas Vondra wrote: > On 08/28/2017 11:23 AM, Antonin Houska wrote: > > Craig Ringer wrote: > > > >> On 25 August 2017 at 15:12, Antonin Houska wrote: > >> > >> How will this play with syslog? csvlog? etc? > > > > There's

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On Mon, Sep 25, 2017 at 6:26 PM, chenhj wrote: > On 2017-09-23 01:59:0, "Alexander Korotkov" > wrote: > > On Fri, Sep 22, 2017 at 7:16 PM, chenhj wrote: > >> This is the new pacth with TAP test and use Macro XLOGDIR. >> > > Good.

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On Wed, Sep 27, 2017 at 1:00 PM, Andres Freund wrote: > We could relatively easily move it to be once-per-postmaster start for > !EXEC_BACKEND builds. Constantly doing expensive binary searches is also > pretty brute force ;) I think one useful way to look at it might be -

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

Hi, On 2017-09-13 23:34:18 -0700, Andres Freund wrote: >I'm not yet super sure about the implementation. For one, I'm not >sure this shouldn't instead be stringinfo.h functions, with very very >tiny pqformat.h wrappers. But conversely I think it'd make a lot of >sense for the

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

Hi, Am Mittwoch, den 27.09.2017, 10:10 -0400 schrieb Peter Eisentraut: > On 9/11/17 03:11, Michael Banck wrote: > > So my patch only moves the slot creation slightly further forward, > > AFAICT. > > I have committed this patch, along with some associated cleanup. Thanks! > > AIUI, wal

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On 2017-09-27 11:50:56 -0400, Tom Lane wrote: > Robert Haas writes: > > I suppose an even better approach would be to build a perfect hash > > table at compile time so that nothing needs to be built at run-time at > > all, but I'm not sure it's worth the trouble. > > Yeah,

Re: [HACKERS] Pluggable storage

Hi! I took a look on this patch. I've following notes for now. tuple_insert_hook tuple_insert; /* heap_insert */ > tuple_update_hook tuple_update; /* heap_update */ > tuple_delete_hook tuple_delete; /* heap_delete */ I don't think this set of functions provides good enough level of

Re: [HACKERS] Multicolumn hash indexes

On Wed, Sep 27, 2017 at 11:57 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Sep 27, 2017 at 9:56 AM, Jesper Pedersen >> wrote: >>> Maybe an initial proof-of-concept could store the hash of the first column >>> (col1)

Re: [HACKERS] Multicolumn hash indexes

Robert Haas writes: > On Wed, Sep 27, 2017 at 9:56 AM, Jesper Pedersen > wrote: >> Maybe an initial proof-of-concept could store the hash of the first column >> (col1) plus the hash of all columns (col1, col2, col3) in the index, and see >> what

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

Robert Haas writes: > I suppose an even better approach would be to build a perfect hash > table at compile time so that nothing needs to be built at run-time at > all, but I'm not sure it's worth the trouble. Yeah, I was wondering about that too. It would likely mean

Re: [HACKERS] [PATCH] Improve geometric types

> The patch replace pg_hypot with hypot in libc. The man page says > as follows. > > man 3 hypot >> If the result overflows, a range error occurs, and the functions return >> HUGE_VAL, HUGE_VALF, or HUGE_VALL, respectively. > .. >>ERRORS >> See math_error(7) for information on

Re: [HACKERS] 200 = 199 + 1?

Marko Tiikkaja writes: > I just came across this very peculiar behavior: I think this is a consequence of the clamping + fallback logic in eqjoinsel_semi. The planner has no info about the inner select's result, except it can see the LIMIT clause so it uses that as a rowcount

Re: [HACKERS] Multicolumn hash indexes

On Wed, Sep 27, 2017 at 9:56 AM, Jesper Pedersen wrote: > Maybe an initial proof-of-concept could store the hash of the first column > (col1) plus the hash of all columns (col1, col2, col3) in the index, and see > what requirements / design decisions would appear from

Re: [HACKERS] Multicolumn hash indexes

On Wed, Sep 27, 2017 at 09:56:26AM -0400, Jesper Pedersen wrote: > On 09/26/2017 08:11 PM, Robert Haas wrote: > >On Tue, Sep 26, 2017 at 7:18 PM, Tom Lane wrote: > >>Tomasz Ostrowski writes: > >>>I've noticed that hash indexes can't currently (in PG10)

Re: [HACKERS] Multicolumn hash indexes

On Tue, Sep 26, 2017 at 11:32 PM, Tom Lane wrote: > There is a facility in the planner to require a condition for the first > column of an index before considering an indexscan plan. We could perhaps > extend that to require a condition for each column of the index, though >

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On Wed, Sep 27, 2017 at 11:18 AM, Robert Haas wrote: > No, I think what Andres is saying is that we ought to build the hash > table before we ever reach this function, so that we don't have to > have a branch here to check whether it's been done. I don't see why > that's

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On Mon, Sep 25, 2017 at 8:42 AM, Jeevan Ladhe wrote: > As Andres has already pointed, may be we want to move above code in a > separate > function, and just call that function here in case the hash is not already > built. No, I think what Andres is saying is that

Re: [HACKERS] Enhancements to passwordcheck

Bossart, Nathan wrote: > On 9/27/17, 7:41 AM, "Peter Eisentraut" > wrote: > > On 9/25/17 23:10, Bossart, Nathan wrote: > >> One interesting design challenge will be how to handle pre-hashed > >> passwords, since the number of checks we can do on those is pretty

Re: [HACKERS] Enhancements to passwordcheck

On 9/27/17, 7:41 AM, "Peter Eisentraut" wrote: > On 9/25/17 23:10, Bossart, Nathan wrote: >> One interesting design challenge will be how to handle pre-hashed >> passwords, since the number of checks we can do on those is pretty >> limited. I'm currently

Re: [BUGS] [HACKERS] Float value 'Infinity' is cast to numeric 1 on Windows

Kohei KaiGai writes: > Does it make sense to put a check of "isinf(val)" and ereport prior to > the snprintf()? Yeah, that was my reaction too. Obviously this wasn't thought about in the original coding ... regards, tom lane -- Sent via

Re: [HACKERS] Logical Replication - test_decoding - unchanged-toast-datum

Hello Euler, Thank you very for your prompt response. I am really very sorry that I didn't mention about my exact question. So as you can see from my previous email, in the replication slot I see the value '*unchanged-toast-datum*' for the column of dataytpe '*character varying*'. Based on

Re: [HACKERS] Logical Replication - test_decoding - unchanged-toast-datum

2017-09-26 21:46 GMT-03:00 Abhinav Singh : > Based on this, when I query my target PostgreSQL instance after the UPDATE > statement is run, the value in this column gets changed to > 'unchanged-toast-datum'. The steps that I gave is a simple reproduction and > I would

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

On 9/11/17 03:11, Michael Banck wrote: > So my patch only moves the slot creation slightly further forward, > AFAICT. I have committed this patch, along with some associated cleanup. > AIUI, wal streaming always begins at last checkpoint and from my tests > the restart_lsn of the created

Re: [HACKERS] Multicolumn hash indexes

On 09/26/2017 08:11 PM, Robert Haas wrote: On Tue, Sep 26, 2017 at 7:18 PM, Tom Lane wrote: Tomasz Ostrowski writes: I've noticed that hash indexes can't currently (in PG10) be multicolumn. Are they technically hard to implement or just nobody took

Re: [HACKERS] [POC] hash partitioning

On 09/27/2017 03:05 AM, amul sul wrote: Attached rebased patch, thanks. While reading through the patch I thought it would be better to keep MODULUS and REMAINDER in caps, if CREATE TABLE was in caps too in order to highlight that these are "keywords" for hash partition. Also updated some of

Re: [HACKERS] Multicolumn hash indexes

On Tue, Sep 26, 2017 at 11:32:52PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Tue, Sep 26, 2017 at 7:18 PM, Tom Lane wrote: > >> It's not simple, particularly not if you wish that the index would support > >> queries specifying conditions for

[HACKERS] Re: ALTER enums (was Re: [COMMITTERS] pgsql: doc: first draft of Postgres 10 release notes)

Andrew Dunstan wrote: > It looks like this is moot anyway, I think the consensus is to remove > the feature and try again in release 11. Oh, crap, I didn't realize it had gone badly. Thanks, -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

[HACKERS] Re: ALTER enums (was Re: [COMMITTERS] pgsql: doc: first draft of Postgres 10 release notes)

On 09/27/2017 06:05 AM, Alvaro Herrera wrote: > Bruce Momjian wrote: >> doc: first draft of Postgres 10 release notes > I noticed that this item > > + > + > +Reduce locking required for adding values to enum types (Andrew Dunstan, > +Tom Lane) > + > + > + > +Previously it was impossible to run

Re: [HACKERS] md5 still listed as an option in pg_hba.conf.sample

On 9/26/17 18:39, Michael Paquier wrote: > On Wed, Sep 27, 2017 at 2:41 AM, Mark Dilger wrote: >> I was under the impression that md5 was removed for this release, per other >> threads that I must not have followed closely enough. > > md5 is still present, its

Re: [HACKERS] Enhancements to passwordcheck

On 9/25/17 23:10, Bossart, Nathan wrote: > One interesting design challenge will be how to handle pre-hashed > passwords, since the number of checks we can do on those is pretty > limited. I'm currently thinking of a parameter that can be used to > block, allow, or force pre-hashed passwords.

Re: [HACKERS] logical replication and statistics

Hi I did recheck and now it looks like it is expected. Probably I did some wrong Sorry for noise Regards Pavel

Re: [HACKERS] Pluggable storage

On Wed, Aug 23, 2017 at 8:26 AM, Haribabu Kommi wrote: > - Minor: don't think the _function suffix for Storis necessary, just >> makes things long, and every member has it. Besides that, it's also >> easy to misunderstand - for a second I understood >>

Re: [HACKERS] Pluggable storage

Hi, Thank you for review on this subject. I think it's extremely important for PostgreSQL to eventually get pluggable storage API. In general I agree with all your points. But I'd like to make couple of comments. On Tue, Aug 15, 2017 at 9:53 AM, Andres Freund wrote: > - I

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On 09/14/2017 12:21 PM, Andres Freund wrote: Hi, Surprising myself I discovered that in workloads that do a large number of fmgr_info* lookups, fmgr_isbuiltin() is actually quite the bottleneck. After discussion with Jeevan Ladhe, we created a sql query which contain lots of inbuild function

Re: [HACKERS] logical decoding of two-phase transactions

> On 7 Sep 2017, at 18:58, Nikhil Sontakke wrote: > > Hi, > > FYI all, wanted to mention that I am working on an updated version of > the latest patch that I plan to submit to a later CF. > Cool! So what kind of architecture do you have in mind? Same way as is it

Re: [HACKERS] Walsender timeouts and large transactions

On 2017-09-12 11:28, Kyotaro HORIGUCHI wrote: Hello, At Wed, 06 Sep 2017 13:46:16 +, Yura Sokolov wrote in <20170906134616.18925.88390.p...@coridan.postgresql.org> I've changed to "need review" to gain more attention from other. I understand that the problem

[HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Hi All, Attaching POC patch that throws an error in the case of a concurrent update to an already deleted tuple due to UPDATE of partition key[1]. In a normal update new tuple is linked to the old one via ctid forming a chain of tuple versions but UPDATE of partition key[1] move tuple from one

Re: [HACKERS] Float value 'Infinity' is cast to numeric 1 on Windows

Hello, Does it make sense to put a check of "isinf(val)" and ereport prior to the snprintf()? It is a lightweight check more than set_var_from_str(). Thanks, 2017-09-27 19:41 GMT+09:00 Taiki Kondo : > Hi all, > > I build PostgreSQL 9.6.5 by Visual Studio 2013 on

[HACKERS] 200 = 199 + 1?

Hi, I just came across this very peculiar behavior: =# create table foo(id int primary key); CREATE TABLE =# insert into foo select generate_series(1, 100); INSERT 0 100 =# set enable_hashjoin to false; set enable_mergejoin to false; SET SET =# explain select * from foo where id in

Re: [HACKERS] Enhancements to passwordcheck

On Wed, Sep 27, 2017 at 6:05 PM, Albe Laurenz wrote: > I had the impression that the reasons why database passwords are > not the best option for high security were: > 1) The password hash is stored in the database and can be stolen and >cracked (don't know if

[HACKERS] Float value 'Infinity' is cast to numeric 1 on Windows

Hi all, I build PostgreSQL 9.6.5 by Visual Studio 2013 on Windows, I found weird behavior on it. I execute following SQL, occurring ERROR is expected, but I got mysterious value 1. postgres=# select (float8 'inf')::numeric; numeric - 1 (1 row) On Windows, at least Visual

Re: [HACKERS] Partition-wise aggregation/grouping

Thanks Ashutosh for reviewing. Attached new patch-set with following changes: 1. Removed earlier 0007 and 0008 patches which were PoC for supporting partial aggregation over fdw. I removed them as it will be a different issue altogether and hence I will tackle them separately once this is done.

[HACKERS] ALTER enums (was Re: [COMMITTERS] pgsql: doc: first draft of Postgres 10 release notes)

Bruce Momjian wrote: > doc: first draft of Postgres 10 release notes I noticed that this item + + +Reduce locking required for adding values to enum types (Andrew Dunstan, +Tom Lane) + + + +Previously it was impossible to run ALTER TYPE ... ADD VALUE in a +transaction block unless the enum type

Re: [HACKERS] Enhancements to passwordcheck

Nathan Bossart wrote: >> As was pointed out in the original discussion >> d960cb61b694cf459dcfb4b0128514c203937...@exadv11.host.magwien.gv.at >> the weak point of "passwordcheck" is that it does not work very well >> for encrypted passwords. >> The only saving grace is that you can at least check

Re: [HACKERS] pg_stat_wal_write statistics view

On Fri, Sep 22, 2017 at 5:46 PM, Julien Rouhaud wrote: > Hello, > > On Wed, Sep 13, 2017 at 3:01 AM, Haribabu Kommi > wrote: > > I ran the latest performance tests with and without IO times, there is an > > overhead involved with IO time calculation

Re: [HACKERS] A design for amcheck heapam verification

On Thu, Sep 7, 2017 at 11:26 AM, Peter Geoghegan wrote: > On Wed, Aug 30, 2017 at 9:29 AM, Peter Geoghegan wrote: >> On Wed, Aug 30, 2017 at 5:02 AM, Alvaro Herrera >> wrote: >>> Eh, if you want to optimize it for the case where debug output

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

On Wed, Sep 27, 2017 at 12:06 AM, Simon Riggs wrote: >> I think we should remove the replacement_sort_tuples GUC, and kill >> replacement selection entirely. There is no need to do this for >> Postgres 10. I don't feel very strongly about it. It just doesn't make >> sense

Re: [HACKERS] Surjective functional indexes

On 15 September 2017 at 16:34, Konstantin Knizhnik wrote: > Attached please find yet another version of the patch. Thanks. I'm reviewing it. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

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

On 14 July 2017 at 23:20, Peter Geoghegan wrote: > I think we should remove the replacement_sort_tuples GUC, and kill > replacement selection entirely. There is no need to do this for > Postgres 10. I don't feel very strongly about it. It just doesn't make > sense to continue to

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 18, 2017 at 8:55 PM, Jesper Pedersen wrote: > On 09/15/2017 02:30 AM, amul sul wrote: > >> Attached rebased patch, thanks. >> >> > While reading through the patch I thought it would be better to keep > MODULUS and REMAINDER in caps, if CREATE TABLE was in

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Wed, Sep 27, 2017 at 12:11 PM, Masahiko Sawada wrote: > On Tue, Sep 26, 2017 at 9:50 PM, Robert Haas wrote: >> On Tue, Sep 26, 2017 at 5:06 AM, Masahiko Sawada >> wrote: >>> Based on the review comment from Robert, I'm

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Tue, Sep 26, 2017 at 9:50 PM, Robert Haas wrote: > On Tue, Sep 26, 2017 at 5:06 AM, Masahiko Sawada > wrote: >> Based on the review comment from Robert, I'm planning to do the big >> change to the architecture of this patch so that a backend

Re: [HACKERS] path toward faster partition pruning

On Wed, Sep 27, 2017 at 6:09 AM, Amit Langote wrote: > On 2017/09/27 1:51, Robert Haas wrote: > > On Tue, Sep 26, 2017 at 10:57 AM, Jesper Pedersen > > wrote: > >> One could advocate (*cough*) that the hash partition patch [1] should

Re: [HACKERS] coverage analysis improvements

On Tue, Sep 26, 2017 at 3:45 PM, Michael Paquier wrote: > Except for the plperl patch, I don't have more comments to offer about > this patch set. It would be nice to make configure a bit smarter for > lcov and gcov detection by not hard-failing if gcov can be found but