Re: [HACKERS] Identifying a message in emit_log_hook.

Hello, At Wed, 17 Feb 2016 09:13:01 +, Simon Riggs wrote in > On 17 February 2016 at 08:34, Kyotaro HORIGUCHI < > horiguchi.kyot...@lab.ntt.co.jp> wrote: > > > > > > I'm guessing this would require

Re: [HACKERS] Prepared Statement support for Parallel query

On Thu, Feb 25, 2016 at 8:53 AM, Amit Kapila wrote: >> But if the user says >> they want to PREPARE the query, they are probably not going to fetch >> all rows. > > After PREPARE, user will execute the statement using EXECUTE and > I don't see how user can decide number

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

On Sat, Jan 16, 2016 at 10:23 AM, Amit Kapila wrote: > >On Fri, Jan 15, 2016 at 11:23 AM, Mithun Cy > wrote: > >> On Mon, Jan 4, 2016 at 2:28 PM, Andres Freund wrote: >> >> >> I think at the very least the cache should

[HACKERS] Performance degradation in commit 6150a1b0

>From past few weeks, we were facing some performance degradation in the read-only performance bench marks in high-end machines. My colleague Mithun, has tried by reverting commit ac1d794 which seems to degrade the performance in HEAD on high-end m/c's as reported previously[1], but still we were

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Thu, Feb 25, 2016 at 10:31 AM, Amit Kapila wrote: >> There's no requirement that every session have every tranche >> registered. I think we should consider displaying "extension" for any >> tranche that's not built-in, or at least for tranches that are not >>

Re: [HACKERS] [PATCH v5] GSSAPI encryption support

On Wed, Feb 24, 2016 at 7:12 PM, Robbie Harwood wrote: > David Steele writes: > >> On 2/15/16 12:45 PM, Robbie Harwood wrote: >>> David Steele writes: >>> 1) It didn't apply cleanly to HEAD. It did apply cleanly on a455878

Re: [HACKERS] [PATCH v5] GSSAPI encryption support

On Tue, Feb 16, 2016 at 2:45 AM, Robbie Harwood wrote: > David Steele writes: >> On 2/10/16 4:06 PM, Robbie Harwood wrote: >>> Hello friends, >>> >>> For your consideration, here is a new version of GSSAPI encryption >>> support. For those who prefer,

Re: [HACKERS] get current log file

On Thu, Feb 25, 2016 at 1:15 AM, Euler Taveira wrote: > On 02-02-2016 10:22, Armor wrote: >> As we known, the name of current log file depends on the number of >> seconds (for simple, later I will call it last_syslogger_file_time) >> since Epoch when create new log

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Fri, Feb 19, 2016 at 9:41 PM, Pavel Stehule wrote: > It looks like good idea. Last version are not breaking compatibility - and > I think so it can works. > > I wrote the code, that works on Python2 and Python3 Hi, I've attached a patch on top of yours with some

Re: [HACKERS] The plan for FDW-based sharding

On Wed, Feb 24, 2016 at 11:34 PM, Bruce Momjian wrote: > On Wed, Feb 24, 2016 at 12:17:28PM +0300, Alexander Korotkov wrote: >> Hi, Bruce! >> >> The important point for me is to distinguish different kind of plans: >> implementation plan and research plan. >> If we're talking

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Wed, Feb 24, 2016 at 7:14 PM, Robert Haas wrote: > On Mon, Feb 22, 2016 at 10:05 AM, Amit Kapila > wrote: > >> I wouldn't bother tinkering with it at this point. The value isn't > >> going to be recorded on disk anywhere, so it will be easy to

Re: [HACKERS] Prepared Statement support for Parallel query

On Wed, Feb 24, 2016 at 7:27 PM, Robert Haas wrote: > On Wed, Feb 17, 2016 at 6:41 PM, Amit Kapila > wrote: > > Commit d1b7c1ffe72e86932b5395f29e006c3f503bc53d has added > > the support for passing bind parameters to parallel workers, however > >

Re: [HACKERS][PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

On 2/24/16, Vitaly Burovoy wrote: > On 2/2/16, Jim Nasby wrote: >> On 2/2/16 6:39 PM, Tom Lane wrote: >>> I'm inclined to think that a good solution would be to create an >>> artificial restriction to not accept years beyond, say, 10 AD.

Re: [HACKERS] Random note of encouragement

On Thu, Feb 25, 2016 at 1:43 PM, Bruce Momjian wrote: > On Thu, Feb 25, 2016 at 12:50:06PM +1300, Thomas Munro wrote: >> On Thu, Feb 25, 2016 at 12:26 PM, Bruce Momjian wrote: >> > On Thu, Feb 25, 2016 at 10:06:34AM +1100, James Sewell wrote: >> >> Now when I

Re: [HACKERS] Random note of encouragement

On Thu, Feb 25, 2016 at 12:50:06PM +1300, Thomas Munro wrote: > On Thu, Feb 25, 2016 at 12:26 PM, Bruce Momjian wrote: > > On Thu, Feb 25, 2016 at 10:06:34AM +1100, James Sewell wrote: > >> Now when I run the following SQL (multiple times to allow for getting > >> everything

Re: [HACKERS] Random note of encouragement

Argh seems like a false alarm for now. I installed 9.5 from RPM source (the other was one I had installed previously) and the performance matched 9.6 Sorry about that, I must have *something* screwed up on the other one. Cheers, James Sewell, PostgreSQL Team Lead / Solutions Architect

Re: [HACKERS] Random note of encouragement

On 25 February 2016 at 12:50, Thomas Munro wrote: > On Thu, Feb 25, 2016 at 12:26 PM, Bruce Momjian wrote: >> On Thu, Feb 25, 2016 at 10:06:34AM +1100, James Sewell wrote: >>> I get the following results: >>> >>> >>> PSQL 9.5 - ~21 seconds >>>

Re: [HACKERS] Random note of encouragement

I've actually just tested this on 9.3 - and I get roughly the same as 9.6devel. Now going back to make sure my 9.5 environment is sane. Hopefully this isn't me jumping the gun. Cheers, James Sewell, PostgreSQL Team Lead / Solutions Architect __ Level 2,

Re: [HACKERS] Random note of encouragement

On Thu, Feb 25, 2016 at 12:26 PM, Bruce Momjian wrote: > On Thu, Feb 25, 2016 at 10:06:34AM +1100, James Sewell wrote: >> Now when I run the following SQL (multiple times to allow for getting >> everything into shared buffers, which is 4GB on my machine): >> >> >> select

Re: [HACKERS] Random note of encouragement

On Thu, Feb 25, 2016 at 10:06:34AM +1100, James Sewell wrote: > Now when I run the following SQL (multiple times to allow for getting > everything into shared buffers, which is 4GB on my machine): > > > select sum(count_n) from base group by view_time_day; > > > I get the following

[HACKERS] Random note of encouragement

Hey All, I've been doing some (futile) work trying to speed up aggregates with a group by in PostgreSQL 9.5. I installed PostgreSQL 9.6 on the same machine to see if I could get anything running in parallel when using partitioning - which didn't work. But - I did find this: With the following

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

Could you enhance the documentation about the difference between "wait event type name" and "wait event name" (examples?)? This is likely to be quite confusing for users who are used to just the plain "waiting" column. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 1/18/16 4:21 PM, Robert Haas wrote: > One idea that occurs to me is: If you can DECLARE BAR FOO%TYPE, but > then you want to make BAR an array of that type rather than a scalar, > why not write that as DECLARE BAR FOO%TYPE[]? That seems quite > natural to me. Right, and it's arguably dubious

Re: [HACKERS] get current log file

On 02-02-2016 10:22, Armor wrote: > As we known, the name of current log file depends on the number of > seconds (for simple, later I will call it last_syslogger_file_time) > since Epoch when create new log file. So, for this feature, the key is > how syslogger process pass

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 18/02/16 15:38, Dmitry Dolgov wrote: Hi As far as I see there is one basic update function for jsonb, that can't be covered by `jsonb_set` - insert a new value into an array at arbitrary position. Using `jsonb_set` function we can only append into array at the end/at the beginning, and it

Re: [HACKERS] [PATCH v5] GSSAPI encryption support

David Steele writes: > On 2/15/16 12:45 PM, Robbie Harwood wrote: >> David Steele writes: >> >>> 1) It didn't apply cleanly to HEAD. It did apply cleanly on a455878 >>> which I figured was recent enough for testing. I didn't bisect to find >>> the

Re: [HACKERS] get current log file

As we known, the name of current log file depends on the number of seconds (for simple, later I will call it last_syslogger_file_time) since Epoch when create new log file. So, for this feature, the key is how syslogger process pass last_syslogger_file_time to backend processes. To pass

Re: [HACKERS] Allow to specify (auto-)vacuum cost limits relative to the database/cluster size?

On 02/24/2016 08:54 AM, Alvaro Herrera wrote: > Joe Conway wrote: > >> In my experience it is almost always best to run autovacuum very often >> and very aggressively. That generally means tuning scaling factor and >> thresholds as well, such that there are never more than say 50-100k dead >>

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi 2016-02-24 10:48 GMT+01:00 Artur Zakirov : On 21.02.2016 11:31, Pavel Stehule wrote: > >> Hi >> >> I am sending updated version - the changes are related to fix comments. >> >> > Great. > > I am new in reviewing, I think Pavel took into account all comments. This >

Re: [HACKERS] Declarative partitioning

> > Hm, I see. How about multi-column keys? Do we care enough about that use > case? I don't see a nice-enough-looking range literal for such keys. > Consider for instance, > > With the partitioned table defined as: > > CREATE TABLE foo(c1 char(2), c2 char(2)) PARTITION BY RANGE (c1, c2); >

Re: [HACKERS] Proposal: Generic WAL logical messages

Hello, It seems that you forgot regression tests for test_decoding. There is an entry in test_decoding/Makefile, but there are not files sql/messages.sql and expected/messages.out. However they are included in the first version of the patch. Hi, yes, git add missing. -- Petr Jelinek

Fw: Re: [HACKERS] get current log file

Sorry， forgot forwarding the mail to the mail list. Please put some comments. -- Jerry Yu https://github.com/scarbrofair -- Original -- From: "Armor";; Date: Tue, Feb 2, 2016 09:22 PM To: "Alvaro

Re: [HACKERS] Allow to specify (auto-)vacuum cost limits relative to the database/cluster size?

Joe Conway wrote: > In my experience it is almost always best to run autovacuum very often > and very aggressively. That generally means tuning scaling factor and > thresholds as well, such that there are never more than say 50-100k dead > rows. Then running vacuum with no delays or limits runs

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

Thank you for remembering this problem, at least for me. Well, turns out there's a quite significant difference, actually. The index sizes I get (quite stable after multiple runs): 9.5 : 2428 MB 9.6 + alone cleanup : 730 MB 9.6 + pending lock : 488 MB Interesting, I don't see why

Re: [HACKERS] Allow to specify (auto-)vacuum cost limits relative to the database/cluster size?

On 02/23/2016 10:23 PM, Robert Haas wrote: > On Tue, Jan 12, 2016 at 6:12 PM, Andres Freund wrote: >> right now the defaults for autovacuum cost limiting are so low that they >> regularly cause problems for our users. It's not exactly obvious that >> any installation above a

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

Hi, On 09/30/2015 03:12 AM, David Rowley wrote: ... CREATE TABLE f (id1 INT, id2 INT, PRIMARY KEY (id1, id2)); CREATE TABLE d1 (id1 INT, id2 INT, FOREIGN KEY (id1, id2) REFERENCES f(id1, id2)); CREATE TABLE d2 (id1 INT, id2 INT, FOREIGN KEY (id1, id2) REFERENCES f(id1,

Re: [HACKERS] The plan for FDW-based sharding

On Wed, Feb 24, 2016 at 01:02:21PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > On Wed, Feb 24, 2016 at 01:08:29AM +, Simon Riggs wrote: > > > > It's never been our policy to try to include major projects in single code > > > drops. Any move of XL/XC code into PostgreSQL core would

Re: [HACKERS] The plan for FDW-based sharding

Bruce Momjian wrote: > On Wed, Feb 24, 2016 at 01:08:29AM +, Simon Riggs wrote: > > It's never been our policy to try to include major projects in single code > > drops. Any move of XL/XC code into PostgreSQL core would need to be done > > piece > > by piece across many releases. XL is

Re: [HACKERS] The plan for FDW-based sharding

On Wed, Feb 24, 2016 at 09:34:37AM -0500, Bruce Momjian wrote: > > I have nothing against particular FDW advances. However, it's unclear for me > > that FDW should be the only sharding approach. > > It's unproven that FDW can do work that Postgres XC/XL does. With FDW we can > > have some 

Re: [HACKERS] The plan for FDW-based sharding

On Wed, Feb 24, 2016 at 12:22:20PM +0300, Konstantin Knizhnik wrote: > Sorry, but based on this plan it is possible to make a conclusion > that there are only two possible cluster solutions for Postgres: > XC/XL and FDW-based. From my point of view there are much more > possible alternatives. >

Re: [HACKERS] The plan for FDW-based sharding

On Wed, Feb 24, 2016 at 12:35:15PM +0300, Oleg Bartunov wrote: > I have nothing against particular FDW advances. However, it's unclear for > me that FDW should be the only sharding approach. > It's unproven that FDW can do work that Postgres XC/XL does. With FDW we > can have some 

Re: [HACKERS] The plan for FDW-based sharding

On Wed, Feb 24, 2016 at 12:17:28PM +0300, Alexander Korotkov wrote: > Hi, Bruce! > > The important point for me is to distinguish different kind of plans: > implementation plan and research plan. > If we're talking about implementation plan then it should be proven that > proposed approach works

Re: [HACKERS] Prepared Statement support for Parallel query

On Wed, Feb 17, 2016 at 6:41 PM, Amit Kapila wrote: > Commit d1b7c1ffe72e86932b5395f29e006c3f503bc53d has added > the support for passing bind parameters to parallel workers, however > prepared statement which uses bind parameters wasn't enabled > for parallel query as

Re: [HACKERS] Prepared Statement support for Parallel query

On Wed, Feb 17, 2016 at 6:41 PM, Amit Kapila wrote: > Commit d1b7c1ffe72e86932b5395f29e006c3f503bc53d has added > the support for passing bind parameters to parallel workers, however > prepared statement which uses bind parameters wasn't enabled > for parallel query as

Re: [HACKERS] Writing new unit tests with PostgresNode

On Tue, Feb 23, 2016 at 10:39 PM, Craig Ringer wrote: > Just finished doing that. Thanks for taking a look at the first patch so > quickly. I hope this one's better. > > FWIW I think you were right that using pod for the actual test wasn't the > best choice, I should've

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Feb 22, 2016 at 10:05 AM, Amit Kapila wrote: >> I wouldn't bother tinkering with it at this point. The value isn't >> going to be recorded on disk anywhere, so it will be easy to change >> the way it's computed in the future if we ever need to do that. >> > >

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

On 02/24/2016 06:56 AM, Robert Haas wrote: On Wed, Feb 24, 2016 at 9:17 AM, Tomas Vondra wrote: ... Are we going to anything about this? While the bug is present in 9.5 (and possibly other versions), fixing it before 9.6 gets out seems important because

Re: [HACKERS] WIP: Failover Slots

On 24 February 2016 at 03:53, Oleksii Kliukin wrote: > > I found the following issue when shutting down a master with a connected > replica that uses a physical failover slot: > > 2016-02-23 20:33:42.546 CET,,,54998,,56ccb3f3.d6d6,3,,2016-02-23 20:33:07 >

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 21.02.2016 11:31, Pavel Stehule wrote: Hi I am sending updated version - the changes are related to fix comments. Great. I am new in reviewing, I think Pavel took into account all comments. This patch is compiled and regression tests are passed. So I change its status to "Ready for

Re: [HACKERS] The plan for FDW-based sharding

On Wed, Feb 24, 2016 at 12:17 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > Hi, Bruce! > > The important point for me is to distinguish different kind of plans: > implementation plan and research plan. > If we're talking about implementation plan then it should be proven that >

Re: [HACKERS] The plan for FDW-based sharding

Sorry, but based on this plan it is possible to make a conclusion that there are only two possible cluster solutions for Postgres: XC/XL and FDW-based. From my point of view there are much more possible alternatives. Our main idea with XTM (eXtensible Transaction Manager API) was to make it

Re: [HACKERS] The plan for FDW-based sharding

Hi, Bruce! The important point for me is to distinguish different kind of plans: implementation plan and research plan. If we're talking about implementation plan then it should be proven that proposed approach works in this case. I.e research should be already done. If we're talking about

Re: [HACKERS] Convert pltcl from strings to objects

On Tue, 23 Feb 2016 17:14:26 -0600 Jim Nasby wrote: > On 2/23/16 6:04 AM, Victor Wagner wrote: > > > Please, send updated patch to the list in this thread, so it would > > appear in the commitfest and I can mark your patch as "ready for > > committer". > > Done!

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Feb 24, 2016 at 5:37 PM, Kyotaro HORIGUCHI wrote: > Hello, > > Ok, I think we should concentrate the parser part for now. > > At Tue, 23 Feb 2016 17:44:44 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in >

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, Ok, I think we should concentrate the parser part for now. At Tue, 23 Feb 2016 17:44:44 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160223.17.178687579.horiguchi.kyot...@lab.ntt.co.jp> > Hello, > > At Mon, 22 Feb 2016 22:52:29 +0900,

Re: [HACKERS] Declarative partitioning

On 2016/02/20 5:06, Corey Huinker wrote: > On Thu, Feb 18, 2016 at 12:41 AM, Amit Langote wrote: > >> START [ EXCL ] (startval) END [ INCL ] (endval) >> >> That is, in range type notation, '[startval, endval)' is the default >> behavior. So for each partition, there is at least the following