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] [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] 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] 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] 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: \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] 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] 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] 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 >

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] 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] 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] 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] 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] 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] 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 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] 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

[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] 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] 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] 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] 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: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] Protect syscache from bloating with negative cache entries

Hello, I have tried to cap the number of negative entries for myself (by removing negative entries in least recentrly created first order) but the ceils cannot be reasonably determined both absolutely or relatively to positive entries. Apparently it differs widely among caches and applications.

Re: [HACKERS] Protect syscache from bloating with negative cache entries

Hello, thank you for lookin this. At Mon, 23 Jan 2017 16:54:36 -0600, Jim Nasby wrote in <21803f50-a823-c444-ee2b-9a153114f...@bluetreble.com> > On 1/21/17 6:42 PM, Jim Nasby wrote: > > On 12/26/16 2:31 AM, Kyotaro HORIGUCHI wrote: > >> The points of discussion are the

Re: [HACKERS] Failure in commit_ts tap tests

On 01/23/2017 09:22 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 01/23/2017 09:03 AM, Tom Lane wrote: >>> Andrew Dunstan writes: On 01/20/2017 01:22 PM, Tom Lane wrote: > It looks like at least part of the answer is

Re: [HACKERS] WIP: About CMake v2

On 24 Jan. 2017 18:00, "Andres Freund" wrote: On 2017-01-24 15:50:47 +0900, Michael Paquier wrote: > I am marking this patch as "returned with feedback". That's quite a > heavy change and it looks to be too late in the development cycle of > PG10 to consider it. Peter's

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

I would suggest to assume false on everything else, and/or maybe to ignore the whole if/endif section in such cases. +1, it also halves the number of values we have to support later. After giving it some thought, I revise a little bit my opinion: I think that if the value is evaluated to

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

On Tue, Jan 24, 2017 at 5:07 AM, Jim Nasby wrote: > I took a look at this again, and it doesn't appear to be working for me. The > library is being loaded during startup, but I don't see any further activity > in the log, and I don't see an autoprewarm file in $PGDATA.

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: [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)

> > 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: \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: \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] [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] 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: \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: [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: [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: [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 ..

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] Add pgstathashindex() to get hash index table statistics.

On Tue, Jan 24, 2017 at 10:09 AM, Ashutosh Sharma wrote: >> I've looked at the patch. It looks good. However, I was wondering why >> an exclusive lock for extension is necessary for reading the number >> blocks in this case. Please refer to the following code. >> >> +

Re: [HACKERS] parallelize queries containing subplans

On Tue, Jan 24, 2017 at 10:59 AM, Amit Kapila wrote: > On Thu, Jan 19, 2017 at 4:51 PM, Dilip Kumar wrote: >> On Thu, Jan 19, 2017 at 3:05 PM, Dilip Kumar wrote: >>> During debugging I found that subplan created for below

Re: [HACKERS] Failure in commit_ts tap tests

On 01/24/2017 03:18 AM, Andrew Dunstan wrote: > > On 01/23/2017 09:22 AM, Tom Lane wrote: >> Andrew Dunstan writes: >>> On 01/23/2017 09:03 AM, Tom Lane wrote: Andrew Dunstan writes: > On 01/20/2017 01:22 PM, Tom Lane

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

On Tue, Jan 24, 2017 at 1:56 PM, Mithun Cy wrote: > On Tue, Jan 24, 2017 at 5:07 AM, Jim Nasby > wrote: > > I took a look at this again, and it doesn't appear to be working for me. > The library is being loaded during startup, but I don't

Re: [HACKERS] Failure in commit_ts tap tests

On 01/24/2017 05:17 AM, Alvaro Herrera wrote: > Andrew Dunstan wrote: > >> Well, that crashed. The DDL deparse comment test should not assume that >> contrib_regression exists. Possibly it should create it if it doesn't >> exist. The buildfarm mostly runs with USE_DB_MODULE=1 so we don't >>

Re: [HACKERS] Cache Hash Index meta page.

On Wed, Jan 18, 2017 at 11:51 AM, Mithun Cy wrote: > On Tue, Jan 17, 2017 at 10:07 AM, Amit Kapila wrote: > >> (b) Another somewhat bigger problem is that with this new change it >> won't retain the pin on meta page till the end which means we

Re: [HACKERS] Failure in commit_ts tap tests

Andrew Dunstan wrote: > Well, that crashed. The DDL deparse comment test should not assume that > contrib_regression exists. Possibly it should create it if it doesn't > exist. The buildfarm mostly runs with USE_DB_MODULE=1 so we don't > constantly overwrite the same db. Maybe we can drop that

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Sorry, this is the continuation of the previous comment. At Wed, 18 Jan 2017 17:36:12 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170118.173612.13506164.horiguchi.kyot...@lab.ntt.co.jp> > Hello. > > (I apologize in advance for possible

Re: [HACKERS] Speedup twophase transactions

>> Speeding up recovery or failover activity via a faster promote is a >> desirable thing. So, maybe, we should look at teaching the relevant >> code about using "KnownPreparedList"? I know that would increase the >> size of this patch and would mean more testing, but this seems to be >> last

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

Hello! I see your point on alternatives. I will do my best to generate more ideas on how vacuum can be done withing existing index structure, this will take a day or two. In this message I'll answer some questions. 2017-01-23 22:45 GMT+05:00 Jeff Davis : > 1. I haven't seen

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

2017-01-18 3:57 GMT+01:00 Peter Eisentraut : > > On 1/13/17 9:22 AM, Peter Moser wrote: > > The goal of temporal aligners and normalizers is to split ranges to allow a > > reduction from temporal queries to their non-temporal counterparts. > > Splitting > > ranges

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

On Mon, Jan 23, 2017 at 6:59 PM, Stephen Frost 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. > > > > But I don't see any proposals to actually change all uses of "xlog" to > >

[HACKERS] Superowners

So I was thinking about various annoying admin/security issues recently, so I came up with this: a new type of user called a “superowner”. It’s somewhere between a superuser and a normal user. Superowner would own all objects defined by users, so it would do useful things in contexts where

Re: [HACKERS] patch proposal

On 1/23/17 10:52 PM, Michael Paquier wrote: > On Tue, Jan 24, 2017 at 7:22 AM, David Steele wrote: >> 3) There are no tests. I believe that >> src/test/recovery/t/006_logical_decoding.pl would be the best place to >> insert your tests. > > 003_recovery_targets.pl is the

Re: [HACKERS] Checksums by default?

On Tue, Jan 24, 2017 at 4:07 AM, Tom Lane wrote: > Peter Geoghegan writes: >> I thought that checksums went in in part because we thought that there >> was some chance that they'd find bugs in Postgres. > > Not really. AFAICS the only point is to catch

Re: [HACKERS] Speedup twophase transactions

> On 24 Jan 2017, at 09:42, Michael Paquier wrote: > > On Mon, Jan 23, 2017 at 9:00 PM, Nikhil Sontakke > wrote: >> Speeding up recovery or failover activity via a faster promote is a >> desirable thing. So, maybe, we should look at teaching

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] 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] 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] 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] 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] 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] 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] 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] 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

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] 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

[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] 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] 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] [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] 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] 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 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] 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] 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] \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: [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] 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

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: 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] 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] 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] [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] 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] 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] 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: [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: [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] 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] 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

  1   2   >