Re: [HACKERS] Declarative partitioning - another take

Hi Ashutosh, On 2017/01/25 14:54, Ashutosh Bapat wrote: > The documentation available at > https://www.postgresql.org/docs/devel/static/sql-createtable.html, > does not make it clear that the lower bound of a range partition is > always inclusive and the higher one is exclusive. I think a note in

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

On 1/23/17, Haribabu Kommi wrote: > The patch is split into two parts. > 1. Macaddr8 datatype support > 2. Contrib module support. Hello, I'm sorry for the delay. The patch is almost done, but I have two requests since the last review. 1. src/backend/utils/adt/mac8.c:

Re: [HACKERS] pgbench more operators & functions

I agree, and I think that's pretty much what we all said back in October, and the patch hasn't been revised since then to match those comments. Hmmm. It really had been revised, although I forgot to remove the "if" doc but I had remove the if function. -- Fabien. -- Sent via

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

2017-01-24 22:29 GMT+05:00 Jeff Davis : > On Tue, Jan 24, 2017 at 3:18 AM, Andrew Borodin wrote: >> Technically, approach of locking a subtree is not novel. Lehman and >> Yao focused on "that any process for manipulating the tree uses only a >> small

Re: [HACKERS] I could not see any row in audit table

On 25 January 2017 at 13:28, Shailesh Singh wrote: > Dear Group Member , > > > I had configured the audit trigger for my datbase following the below > document url: > > https://wiki.postgresql.org/wiki/Audit_trigger_91plus That is not part of PostgreSQL proper.

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 25 January 2017 at 13:44, Craig Ringer wrote: > On 24 January 2017 at 23:49, Robert Haas wrote: > >> I think it's fairly surprising that TruncateCLOG() has responsibility >> for writing the xlog record that protects advancing >>

Re: [HACKERS] \h tab-completion

On Wed, Jan 25, 2017 at 11:43 AM, Michael Paquier wrote: > On Wed, Jan 25, 2017 at 3:03 PM, Beena Emerson > wrote: > > I think the following change in tab-complete.c would do the trick. > > > > - else if (Matches1("ALTER")) > > +

Re: [HACKERS] \h tab-completion

On Wed, Jan 25, 2017 at 3:03 PM, Beena Emerson wrote: > I think the following change in tab-complete.c would do the trick. > > - else if (Matches1("ALTER")) > + else if (TailMatches1("ALTER")) Nope. This change breaks a bunch of subcommands, take for example

Re: [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG

On Wed, Jan 25, 2017 at 2:58 PM, Ideriha, Takeshi wrote: > Hi, > > I'm sorry but I think I don't have time to work on this patch in this CF. > I've gotten busy for another work. > > So I moved this patch to next CF with "waiting on author" status. Thanks for doing

Re: [HACKERS] \h tab-completion

On Wed, Jan 25, 2017 at 9:03 AM, Stephen Frost wrote: > All, > > I'm not really inclined to do it myself right now, but it'd be awful > nice if we had better table completion for \h. > > Right now, '\h alter' returns nothing, and '\h alter' returns a > *bunch* of stuff. > >

Re: [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG

Hi, I'm sorry but I think I don't have time to work on this patch in this CF. I've gotten busy for another work. So I moved this patch to next CF with "waiting on author" status. Regards, Ideriha Takeshi > -Original Message- > From: Ideriha, Takeshi > Sent: Friday, January 20, 2017

Re: [HACKERS] multivariate statistics (v19)

On Wed, Jan 4, 2017 at 11:35 AM, Tomas Vondra wrote: > On 01/03/2017 05:22 PM, Tomas Vondra wrote: >> >> On 01/03/2017 02:42 PM, Dilip Kumar wrote: > > ... >>> >>> I think it should be easily reproducible, in case it's not I can send >>> call stack or core dump. >>>

Re: [HACKERS] Declarative partitioning - another take

The documentation available at https://www.postgresql.org/docs/devel/static/sql-createtable.html, does not make it clear that the lower bound of a range partition is always inclusive and the higher one is exclusive. I think a note in section " PARTITION OF parent_table FOR VALUES

Re: [HACKERS] Pinning a buffer in TupleTableSlot is unnecessary

On Mon, Dec 5, 2016 at 11:32 AM, Haribabu Kommi wrote: > > > On Tue, Nov 15, 2016 at 1:17 PM, Noah Misch wrote: >> >> On Mon, Nov 14, 2016 at 10:21:53AM -0800, Peter Geoghegan wrote: >> > BTW, I recently noticed that the latest version of Valgrind,

Re: [HACKERS] pgbench more operators & functions

I'm spending time to try to make something useful of pgbench, which require a bunch of patches that work together to improve it for new use case, including not being limited to the current set of operators. This decision is both illogical and arbitrary. I disagree. I think his decision

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 24 January 2017 at 23:49, Robert Haas wrote: > I think it's fairly surprising that TruncateCLOG() has responsibility > for writing the xlog record that protects advancing > ShmemVariableCache->oldestXid, but not the responsibility for actually > advancing that value.

Re: [HACKERS] COPY as a set returning function

On Mon, Dec 5, 2016 at 2:10 PM, Haribabu Kommi wrote: > On Tue, Nov 1, 2016 at 7:45 AM, Corey Huinker > wrote: >> >> Attached is a patch that implements copy_srf(). > > Moved to next CF with "needs review" status. This patch is still waiting

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

On Wed, Jan 25, 2017 at 2:28 PM, Ashutosh Bapat wrote: > On Wed, Jan 25, 2017 at 10:54 AM, Michael Paquier > wrote: >> On Wed, Jan 25, 2017 at 12:46 AM, Tom Lane wrote: >>> I wrote: Michael Paquier

[HACKERS] I could not see any row in audit table

Dear Group Member , I had configured the audit trigger for my datbase following the below document url: *https://wiki.postgresql.org/wiki/Audit_trigger_91plus * Now my audit table : CREATE TABLE audit.logged_actions ( event_id

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

On Wed, Jan 25, 2017 at 10:54 AM, Michael Paquier wrote: > On Wed, Jan 25, 2017 at 12:46 AM, Tom Lane wrote: >> I wrote: >>> Michael Paquier writes: The table of Pseudo-Types needs to be updated as well with unknown

Re: [HACKERS] pgbench more operators & functions

On Wed, Jan 25, 2017 at 6:38 AM, Robert Haas wrote: > Let's mark this Returned with Feedback and move on. We've only got a > week left in the CommitFest anyhow and there are lots of other things > that still need work (and which actually have been revised to match >

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

On Wed, Jan 25, 2017 at 12:46 AM, Tom Lane wrote: > I wrote: >> Michael Paquier writes: >>> The table of Pseudo-Types needs to be updated as well with unknown in >>> datatype.sgml. > >> Check. > > Here's an updated patch with doc changes. Aside

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Wed, Jan 25, 2017 at 10:36 AM, Jim Nasby wrote: > On 1/24/17 2:26 AM, Mithun Cy wrote: > >> Thanks for looking into this patch, I just downloaded the patch and >> applied same to the latest code, I can see file " autoprewarm.save" in >> $PGDATA which is created and

Re: [HACKERS] Proposal : For Auto-Prewarm.

On 1/24/17 2:26 AM, Mithun Cy wrote: Thanks for looking into this patch, I just downloaded the patch and applied same to the latest code, I can see file " autoprewarm.save" in $PGDATA which is created and dumped at shutdown time and an activity is logged as below 2017-01-24 13:22:25.012 IST

Re: [HACKERS] Proposal : For Auto-Prewarm.

On 1/24/17 4:56 AM, Beena Emerson wrote: 2. buff_dump_interval could be renamed to just dump_interval or buffer_dump_interval. Also, since it is now part of pg_prewarm. I think it makes sense to have the conf parameter be: pg_prewarm.xxx instead of pg_autoprewarm.xxx I'd really like to find

Re: [HACKERS] Checksums by default?

On 1/24/17 10:30 AM, Joshua D. Drake wrote: Tom is correct here. They are not a net win for the average user. We tend to forget that although we collectively have a lot of enterprise installs where this does matter, we collectively do not equal near the level of average user installs. From an

Re: [HACKERS] patch: function xmltable

2017-01-25 5:45 GMT+01:00 Tom Lane : > Andres Freund writes: > > On 2017-01-24 21:32:56 -0300, Alvaro Herrera wrote: > >> XMLTABLE is specified by the standard to return multiple rows ... but > >> then as far as my reading goes, it is only supposed to be

Re: [HACKERS] pg_hba_file_settings view patch

On Tue, Jan 24, 2017 at 6:17 PM, Michael Paquier wrote: > On Mon, Jan 23, 2017 at 5:13 PM, Haribabu Kommi > wrote: > > On Sat, Jan 21, 2017 at 8:01 AM, Tom Lane wrote: > >> * I'm not exactly convinced that the way you

Re: [HACKERS] pg_hba_file_settings view patch

On Wed, Jan 25, 2017 at 9:58 AM, Haribabu Kommi wrote: > > > On Wed, Jan 25, 2017 at 2:50 PM, Ashutosh Bapat > wrote: >> >> On Wed, Jan 25, 2017 at 6:34 AM, Michael Paquier >> wrote: >> > On Tue, Jan 24, 2017

Re: [HACKERS] patch: function xmltable

Hi 2017-01-25 1:35 GMT+01:00 Andres Freund : > On 2017-01-24 21:32:56 -0300, Alvaro Herrera wrote: > > Andres Freund wrote: > > > Hi, > > > > > > On 2017-01-24 17:38:49 -0300, Alvaro Herrera wrote: > > > > +static Datum ExecEvalTableExpr(TableExprState *tstate, ExprContext >

Re: [HACKERS] patch: function xmltable

Andres Freund writes: > On 2017-01-24 21:32:56 -0300, Alvaro Herrera wrote: >> XMLTABLE is specified by the standard to return multiple rows ... but >> then as far as my reading goes, it is only supposed to be supported in >> the range table (FROM clause) not in the target

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On 1/23/17 10:36 PM, Craig Ringer wrote: which is currently returned as [ {"a":1, "b":10}, {"a":2, "b":20} ] instead as { "a": [1, 2], "b": [10, 20] } Correct. If so I see that as a lot more of a niche thing. I can see why it'd be useful and would help performance, but it seems much more

Re: [HACKERS] pg_hba_file_settings view patch

On Wed, Jan 25, 2017 at 2:50 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Wed, Jan 25, 2017 at 6:34 AM, Michael Paquier > wrote: > > On Tue, Jan 24, 2017 at 11:19 PM, Ashutosh Bapat > > wrote: > >> On Mon, Jan 23,

Re: [HACKERS] pg_hba_file_settings view patch

On Wed, Jan 25, 2017 at 6:34 AM, Michael Paquier wrote: > On Tue, Jan 24, 2017 at 11:19 PM, Ashutosh Bapat > wrote: >> On Mon, Jan 23, 2017 at 1:43 PM, Haribabu Kommi >> wrote: >>> >>> >>> On Sat, Jan 21, 2017

[HACKERS] \h tab-completion

All, I'm not really inclined to do it myself right now, but it'd be awful nice if we had better table completion for \h. Right now, '\h alter' returns nothing, and '\h alter' returns a *bunch* of stuff. Yet, we happily support '\h alter view' and friends, returning just the info relevant for

Re: [HACKERS] increasing the default WAL segment size

On Wed, Jan 25, 2017 at 6:58 AM, Robert Haas wrote: > On Fri, Jan 20, 2017 at 7:00 PM, Michael Paquier > wrote: >>> No, because the output of SHOW is always of type text, regardless of >>> the type of the GUC. >> >> Thinking about that over

Re: [HACKERS] pageinspect: Hash index support

On Thu, Jan 19, 2017 at 5:08 PM, Ashutosh Sharma wrote: Thanks, Ashutosh and Jesper. I have tested the patch I do not have any more comments so making it ready for committer. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com -- Sent via

[HACKERS] simplify sequence test

We maintain a separate test output file sequence_1.out because the log_cnt value can vary if there is a checkpoint happening at the right time. So we have to maintain two files because of a one character difference. I propose the attached patch to restructure the test a bit to avoid this,

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/25 5:55, Robert Haas wrote: > On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote > wrote: >> [ new patches ] > > Committed 0001 and 0002. See my earlier email for comments on 0003. It seems patches for all the issues mentioned in this thread so far, except

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/25 2:56, Robert Haas wrote: > On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote > wrote: >>> But I wonder why we don't instead just change this function to >>> consider tdhasoid rather than tdtypeid. I mean, if the only point of >>> comparing the type OIDs

Re: [HACKERS] pg_hba_file_settings view patch

On Tue, Jan 24, 2017 at 11:19 PM, Ashutosh Bapat wrote: > On Mon, Jan 23, 2017 at 1:43 PM, Haribabu Kommi > wrote: >> >> >> On Sat, Jan 21, 2017 at 8:01 AM, Tom Lane wrote: >>> >>> Haribabu Kommi

Re: [HACKERS] Declarative partitioning - another take

Hi Keith, On 2017/01/20 12:40, Keith Fiske wrote: > So testing things out in pg_partman for native sub-partitioning and ran > into what is a bug for me that I know I have to fix, but I'm curious if > this can be prevented in the first place within the native partitioning > code itself. The below

Re: [HACKERS] patch: function xmltable

On 2017-01-24 21:32:56 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > Hi, > > > > On 2017-01-24 17:38:49 -0300, Alvaro Herrera wrote: > > > +static Datum ExecEvalTableExpr(TableExprState *tstate, ExprContext > > > *econtext, > > > + bool *isnull); > > > +static

Re: [HACKERS] patch: function xmltable

Andres Freund wrote: > Hi, > > On 2017-01-24 17:38:49 -0300, Alvaro Herrera wrote: > > +static Datum ExecEvalTableExpr(TableExprState *tstate, ExprContext > > *econtext, > > + bool *isnull); > > +static Datum ExecEvalTableExprFast(TableExprState *exprstate,

Re: [HACKERS] patch: function xmltable

Hi, On 2017-01-24 17:38:49 -0300, Alvaro Herrera wrote: > +static Datum ExecEvalTableExpr(TableExprState *tstate, ExprContext *econtext, > + bool *isnull); > +static Datum ExecEvalTableExprFast(TableExprState *exprstate, ExprContext > *econtext, > +

Re: [HACKERS] PATCH: recursive json_populate_record()

On 22.01.2017 21:58, Tom Lane wrote: In the meantime, we are *not* going to have attndims be semantically significant in just this one function. Therefore, please remove this patch's dependence on attndims. Ok, I've removed patch's dependence on attndims. But I still believe that someday

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_sequence system catalog

On 1/24/17 10:23 AM, Stephen Frost wrote: > It wouldn't hurt to add a comment as to why things are so different in > PG10 than other versions, ie: > > /* > * In PG10, sequence meta-data was moved into pg_sequence, so switch to > * the pg_catalog schema instead of operating in a user schema and

Re: [HACKERS] [PATCH] pgpassfile connection option

Fabien COELHO writes: > I've switch in the CF to "ready for committer", and we'll see what the > next level thinks about it:-) Pushed with a few adjustments: * It seemed to me that the appropriate parameter name is "passfile" not "pgpassfile". In all but a couple of

Re: [HACKERS] Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

On Thu, Nov 24, 2016 at 4:24 PM, Amit Kapila wrote: > On Thu, Nov 24, 2016 at 10:29 AM, Tsunakawa, Takayuki > wrote: >> From: pgsql-hackers-ow...@postgresql.org >>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila >>>

Re: [HACKERS] increasing the default WAL segment size

On Fri, Jan 20, 2017 at 7:00 PM, Michael Paquier wrote: >> No, because the output of SHOW is always of type text, regardless of >> the type of the GUC. > > Thinking about that over night, that looks pretty nice. What would be > nicer though would be to add INT8OID and

Re: [HACKERS] Parallel Index Scans

On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote: > In spite of being careful, I missed reorganizing the functions in > genam.h which I have done in attached patch. Cool. Committed parallel-generic-index-scan.2.patch. Thanks. -- Robert Haas EnterpriseDB:

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Mon, Jan 23, 2017 at 1:55 PM, Peter Eisentraut wrote: > For the record, I don't like the name "xlog" either. It would be nice > if we could have more consistent and intuitive naming. Great! > But I don't see any proposals to actually change all uses of

Re: [HACKERS] pgbench more operators & functions

On Tue, Jan 24, 2017 at 12:58 PM, Tom Lane wrote: > I'd be okay with the parts of this that duplicate existing backend syntax > and semantics, but I don't especially want to invent further than that. I agree, and I think that's pretty much what we all said back in October,

Re: [HACKERS] Declarative partitioning - another take

On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote wrote: > [ new patches ] Committed 0001 and 0002. See my earlier email for comments on 0003. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers

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

2017-01-24 6:38 GMT+01:00 Pavel Stehule : > Hi > > 2017-01-23 21:59 GMT+01:00 Jim Nasby : > >> On 1/23/17 2:10 PM, Pavel Stehule wrote: >> >>> Comments, notes? >>> >> >> +1 on the idea. It'd also be nice if we could expose control of plans for >>

Re: [HACKERS] Improvements in psql hooks for variables

"Daniel Verite" writes: > Here's an update with these changes: I scanned this patch very quickly and think it addresses my previous stylistic objections. Rahila is the reviewer of record though, so I'll wait for his comments before going further.

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Revised patch, with one caveat: It contains copy/pasted code from variable.c intended to bridge the gap until https://commitfest.postgresql. org/12/799/ (changing ParseVariableBool to detect invalid boolean-ish strings) is merged. We may want to pause full-review of this patch pending resolution

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

"Daniel Verite" writes: > ISTM that it's important that eventually ParseVariableBool() > and \if agree on what evaluates to true and false (and the > more straightforward way to achieve that is by \if calling > directly ParseVariableBool), but that it's not productive

Re: [HACKERS] pgbench more operators & functions

"David G. Johnston" writes: > Maybe consider writing a full patch series that culminates with this > additional builtin option being added as the final patch - breaking out > this (and probably other) "requirements" patches separately to aid in > review. The

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

On 2017-01-24 19:25:52 +0100, Tobias Oberstein wrote: > Hi, > > > > pid |syscall| cnt | cnt_per_sec > > > -+---+-+- > > > | syscalls:sys_enter_lseek | 4091584 | 136386 > > >

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Vladimir Rusinov (vrusi...@google.com) wrote: > On Mon, Jan 23, 2017 at 6:59 PM, Stephen Frost wrote: > > I don't have any problem with asking for a summary of the exact set of > > changes that he's planning to make though. My understanding is that it > > includes changing

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

On 2017-01-24 15:36:13 -0300, Alvaro Herrera wrote: > Tobias Oberstein wrote: > > > I am benchmarking IOPS, and while doing so, it becomes apparent that at > > these scales it does matter _how_ IO is done. > > > > The most efficient way is libaio. I get 9.7 million/sec IOPS with low CPU > >

Re: [HACKERS] pgbench more operators & functions

On Wed, Oct 5, 2016 at 2:03 AM, Fabien COELHO wrote: > > I've got no objection to a more-nearly-TPC-B script as an option. >> > > Good, because adding a "per-spec" tpc-b as an additional builtin option is > one of my intentions, once pgbench is capable of it. ​Trying to

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Tue, Jan 24, 2017 at 1:25 PM, Corey Huinker wrote: > This might be asking a lot, but could we make a "strict" mode for > ParseVariableBool() that returns a success boolean, and have the existing > ParseVariableBool() signature call that new function, and issue the >

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Tobias Oberstein wrote: > I am benchmarking IOPS, and while doing so, it becomes apparent that at > these scales it does matter _how_ IO is done. > > The most efficient way is libaio. I get 9.7 million/sec IOPS with low CPU > load. Using any synchronous IO engine is slower and produces higher

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Hi, pid |syscall| cnt | cnt_per_sec -+---+-+- | syscalls:sys_enter_lseek | 4091584 | 136386 | syscalls:sys_enter_newfstat | 2054988 | 68500 |

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > ISTM that it's important that eventually ParseVariableBool() > and \if agree on what evaluates to true and false (and the > more straightforward way to achieve that is by \if calling > directly ParseVariableBool), but that it's not productive that we > discuss /if issues relatively to the

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Hi, On 2017-01-24 18:57:47 +0100, Tobias Oberstein wrote: > Am 24.01.2017 um 18:41 schrieb Andres Freund: > > On 2017-01-24 18:37:14 +0100, Tobias Oberstein wrote: > > > The syscall overhead is visible in production too .. I watched PG using > > > perf > > > live, and lseeks regularily appear at

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Corey Huinker wrote: > > > > 1: unrecognized value "whatever" for "\if"; assuming "on" > > > > I do not think that the script should continue with such an assumption. > > > > I agree, and this means we can't use ParseVariableBool() as-is The patch at

Re: [HACKERS] pgbench more operators & functions

Robert Haas writes: >> On Fri, Dec 2, 2016 at 1:28 AM, Fabien COELHO wrote: >>> This decision is both illogical and arbitrary. >> I disagree. I think his decision was probably based on this email from me: > (argh, sent too soon) >

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Hi, Am 24.01.2017 um 18:41 schrieb Andres Freund: Hi, On 2017-01-24 18:37:14 +0100, Tobias Oberstein wrote: assume that it'd get more than swamped with doing actualy work, and with buffering the frequently accessed stuff in memory. What I am trying to say is: the syscall overhead of doing

Re: [HACKERS] Declarative partitioning - another take

On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote wrote: >> But I wonder why we don't instead just change this function to >> consider tdhasoid rather than tdtypeid. I mean, if the only point of >> comparing the type OIDs is to find out whether the table-has-OIDs >>

Re: [HACKERS] ICU integration

On 1/9/17 3:45 PM, Peter Geoghegan wrote: > * I think it's worth looking into ucol_nextSortKeyPart(), and using > that as an alternative to ucol_getSortKey(). It doesn't seem any > harder, and when I tested it it was clearly faster. (I think that > ucol_nextSortKeyPart() is more or less intended

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Hi, On 2017-01-24 18:37:14 +0100, Tobias Oberstein wrote: > > assume that it'd get more than swamped with doing actualy work, and with > > buffering the frequently accessed stuff in memory. > > > > > > > What I am trying to say is: the syscall overhead of doing lseek/read/write > > > instead of

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Hi, Switching to sync engine, it drops to 9.1 mio - but the system load then is also much higher! I doubt those have very much to do with postgres - I'd quite strongly In the machine in production, we see 8kB reads in the 300k-650k/s range. In spikes, because, yes, due to the 3TB RAM, we

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

On Tue, Jan 24, 2017 at 3:18 AM, Andrew Borodin wrote: > Technically, approach of locking a subtree is not novel. Lehman and > Yao focused on "that any process for manipulating the tree uses only a > small (constant) number of locks at any time." We are locking unknown > and

Re: [HACKERS] Performance improvement for joins where outer side is unique

[ getting back to this at long last ] David Rowley writes: > However, having said that, I'm not sure why we'd need outer_unique > available so we'd know that we could skip mark/restore. I think > inner_unique is enough for this purpose. Take the comment from >

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Hi, On 2017-01-24 18:11:09 +0100, Tobias Oberstein wrote: > I have done lots of benchmarking over the last days on a massive box, and I > can provide numbers that I think show that the impact can be significant. > Above number was using psync FIO engine .. with libaio, it's at 9.7 mio with >

[HACKERS] lseek/read/write overhead becomes visible at scale ..

Hi guys, pls bare with me, this is my first post here. Pls also excuse the length .. I was trying to do all my homework before posting here;) The overhead of lseek/read/write vs pread/pwrite (or even pvread/pvwrite) was previously discussed here

Re: [HACKERS] Improvements in psql hooks for variables

I just wrote: > - add enum-style suggestions on invalid input for \pset x, \pset pager, > and \set of ECHO, ECHO_HIDDEN, ON_ERROR_ROLLBACK, COMP_KEYWORD_CASE, > HISTCONTROL, VERBOSITY, SHOW_CONTEXT, \x, \pager There's no such thing as \pager, I meant to write: \pset x, \pset pager, and

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > I took a quick look through this. It seems to be going in generally > the right direction, but here's a couple of thoughts: Here's an update with these changes: per Tom's suggestions upthread: - change ParseVariableBool() signature to return validity as bool. -

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Fri, Oct 28, 2016 at 6:36 AM, Tsunakawa, Takayuki wrote: > I welcome this feature! I remember pg_hibernate did this. I wonder what > happened to pg_hibernate. Did you check it? Thanks, when I checked with pg_hibernate there were two things people complained

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > However, it only really works if psql never overwrites the values > after startup, whereas I believe all of these are overwritten by > a \c command. Yes, there are reset to reflect the properties of the new connection. > So maybe it's more user-friendly to make these

Re: [HACKERS] logical-replication.sgml improvements

On 2017-01-24 17:29, Robert Haas wrote: On Fri, Jan 20, 2017 at 11:00 AM, Erik Rijkers wrote: logical-replication.sgml.diff changes I had a look at this but these are not all open-and-shut cases. In many cases I think your proposed wording is better, but it's probably a good

Re: [HACKERS] pgbench more operators & functions

On Tue, Jan 24, 2017 at 11:32 AM, Robert Haas wrote: > On Fri, Dec 2, 2016 at 1:28 AM, Fabien COELHO wrote: >>> Closed in 2016-11 commitfest with "returned with feedback" status. >>> Please feel free to update the status once you submit the updated

Re: [HACKERS] pgbench more operators & functions

On Fri, Dec 2, 2016 at 1:28 AM, Fabien COELHO wrote: >> Closed in 2016-11 commitfest with "returned with feedback" status. >> Please feel free to update the status once you submit the updated patch. > > Given the thread discussions, I do not understand why this "ready for >

Re: [HACKERS] Checksums by default?

On 01/21/2017 09:09 AM, Tom Lane wrote: Stephen Frost writes: As for checksums, I do see value in them and I'm pretty sure that the author of that particular feature did as well, or we wouldn't even have it as an option. You seem to be of the opinion that we might as well

Re: [HACKERS] logical-replication.sgml improvements

On Fri, Jan 20, 2017 at 11:00 AM, Erik Rijkers wrote: > logical-replication.sgml.diff changes I had a look at this but these are not all open-and-shut cases. In many cases I think your proposed wording is better, but it's probably a good idea for the people who were involved in

Re: [HACKERS] Deadlock in XLogInsert at AIX

More information about the problem - Postgres log contains several records: 2017-01-24 19:15:20.272 MSK [19270462] LOG: request to flush past end of generated WAL; request 6/AAEBE000, currpos 6/AAEBC2B0 and them correspond to the time when deadlock happen. There is the following comment in

Re: [HACKERS] [ patch ] pg_dump: new --custom-fetch-table and --custom-fetch-value parameters

On Fri, Jan 20, 2017 at 12:52 AM, Andrea Urbani wrote: > I have used "custom" parameters because I want to decrease the fetch size > only on the tables with big bloab fields. If we remove the > "custom-fetch-table" parameter and we provide only the "fetch-size" parameter >

Re: [HACKERS] Checksums by default?

On 21.01.2017 19:35, Tom Lane wrote: Andres Freund writes: Sure, it might be easy, but we don't have it. Personally I think checksums just aren't even ready for prime time. If we had: - ability to switch on/off at runtime (early patches for that have IIRC been posted) -

Re: [HACKERS] Checksums by default?

On 21.01.2017 19:37, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost writes: Because I see having checksums as, frankly, something we always should have had (as most other databases do, for good reason...) and because they will hopefully prevent

Re: [HACKERS] [COMMITTERS] pgsql: Reindent table partitioning code.

On Tue, Jan 24, 2017 at 10:28 AM, Tom Lane wrote: > Robert Haas writes: >> Reindent table partitioning code. > > Oh, thank you, I was starting to get annoyed with that too. Glad you like. The pgindent damage introduced by the logical replication

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On Mon, Jan 23, 2017 at 1:32 AM, Craig Ringer wrote: > Rebased patch attached. I've split the clog changes out from > txid_status() its self. I think it's fairly surprising that TruncateCLOG() has responsibility for writing the xlog record that protects advancing

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

I wrote: > Michael Paquier writes: >> The table of Pseudo-Types needs to be updated as well with unknown in >> datatype.sgml. > Check. Here's an updated patch with doc changes. Aside from that one, I tried to spell "pseudo-type" consistently, and I changed one place

Re: [HACKERS] Active zombies at AIX

On 24.01.2017 18:26, Tom Lane wrote: Konstantin Knizhnik writes: But ps shows that status of process is [14:46:02]root@postgres:~ # ps -elk | grep 25691556 * A - 25691556 - - - - - As far as I could find by googling, this means that the process is not

Re: [HACKERS] Active zombies at AIX

Konstantin Knizhnik writes: > But ps shows that status of process is > [14:46:02]root@postgres:~ # ps -elk | grep 25691556 > * A - 25691556 - - - - - As far as I could find by googling, this means that the process is not actually a zombie yet, so it's not the

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_sequence system catalog

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/19/17 11:03 AM, Stephen Frost wrote: > > I'd suggest using our usual approach in pg_dump, which is matching based > > on the OID, like so: > > > > WHERE c.oid = '%u'::oid > > > > The OID is in: tbinfo->dobj.catId.oid > >

[HACKERS] Active zombies at AIX

Hi hackers, Yet another story about AIX. For some reasons AIX very slowly cleaning zombie processes. If we launch pgbench with -C parameter then very soon limit for maximal number of connections is exhausted. If maximal number of connection is set to 1000, then after ten seconds of pgbench

Re: [HACKERS] [PATCH] Change missleading comment for tm_mon field of pg_tm structure

On Thu, Jan 19, 2017 at 2:52 PM, Dmitry Fedin wrote: > According to usages, tm_mon (month) field has origin 1, not 0. This is > difference from C-library version of struct tm, which has origin 0 for > real. Hmm, thanks for noticing. Looks like it has been wrong for a

  1   2   >