Re: [HACKERS] Optimizing numeric SUM() aggregate

I've tested patch with this query https://gist.github.com/x4m/fee16ed1a55217528f036983d88771b4 Test specs were: Ubuntu 14 LTS VM, dynamic RAM, hypervisor Windows Server 2016, SSD disk, core i5-2500. Configuration: out of the box master make. On 10 test runs timing of select statement: AVG 3739.8

Re: [HACKERS] System load consideration before spawning parallel workers

On Fri, Jul 29, 2016 at 11:26 AM, Haribabu Kommi wrote: > we observed that spawning the specified number of parallel workers for > every query that satisfies for parallelism is sometimes leading to > performance drop compared to improvement during the peak system load >

[HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Hello Some time ago we discussed an idea of "fast temporary tables": https://www.postgresql.org/message-id/20160301182500.2c81c3dc%40fujitsu In two words the idea is following. PostgreSQL stores information about all relations in pg_catalog. Some applications create and delete a lot of

Re: [HACKERS] WAL logging problem in 9.4.3?

On Thu, Jul 28, 2016 at 4:59 PM, Michael Paquier wrote: > On Wed, Apr 6, 2016 at 3:11 PM, Michael Paquier > wrote: >> On Wed, Mar 23, 2016 at 12:45 PM, Michael Paquier >> wrote: >>> On Wed, Mar 23, 2016 at 11:11

Re: [HACKERS] "Strong sides of MySQL" talk from PgDay16Russia, translated

On Thu, Jul 28, 2016 at 8:39 PM, Tatsuo Ishii wrote: > BTW, is there any opposite information, i.e. showing the > limitation of MySQL comparing with PostgreSQL? I'm not aware of a general list on the topic, but in reviewing academic papers regarding transaction isolation I

Re: [HACKERS] pg_basebackup wish list

On Thu, Jul 28, 2016 at 7:34 PM, Fujii Masao wrote: > On Thu, Jul 28, 2016 at 10:16 PM, Amit Kapila wrote: > >> I think there is some value in providing >> .tar for -Z 0, > > I was thinking that "-Ft -Z0" is something like an alias of "-Ft". > That

Re: [HACKERS] Why we lost Uber as a user

On 7/28/16 10:05 AM, Alex Ignatov wrote: Just curious: what if PostgreSQL supported index that stores "primary key" (or unique key) instead of tids? You mean IOT like Oracle have? IIRC, IOT either stores the table in index order, which is something different. What Alex is proposing is an

Re: [HACKERS] "Strong sides of MySQL" talk from PgDay16Russia, translated

On 7/29/16 3:13 PM, David Fetter wrote: > I expect this kind of blather from MySQL, but you've brought up > something that's been bothering me for awhile. PostgreSQL's response > should look more like this: > > ERROR: month field value out of range: "2016-99-99" > LINE 1: select

[HACKERS] Performance of tqueue.c's tuple remapping logic

$SUBJECT sucks. Create a table containing lots of composite arrays: regression=# create table foo (f1 int8_tbl[]); CREATE TABLE regression=# insert into foo select array[row(1,2),row(3,4)]::int8_tbl[] from generate_series (1,1000); INSERT 0 1000 regression=# vacuum analyze foo; VACUUM

Re: [HACKERS] to_date_valid()

On 7/29/16 1:33 PM, Andreas 'ads' Scherbaum wrote: On 27.07.2016 05:00, Joshua D. Drake wrote: On 07/26/2016 06:25 PM, Peter Eisentraut wrote: On 7/5/16 4:24 AM, Albe Laurenz wrote: But notwithstanding your feeling that you would like your application to break if it makes use of this

Re: [HACKERS] "Strong sides of MySQL" talk from PgDay16Russia, translated

On Fri, Jul 29, 2016 at 09:20:12PM +0300, Nikolay Samokhvalov wrote: > On Fri, Jul 29, 2016 at 5:28 PM, Jim Nasby wrote: > > > > The way I sum up MySQL vs PG for people that ask is to recount how they > > "fixed" the Feb. 31st bug when they released strict mode

Re: [HACKERS] Design for In-Core Logical Replication

Robert Haas wrote: > One minor comment is that this document makes extensive use of Terms > With Initial Capitals, which seems stylistically odd, although I'm not > precisely sure what would be better. We use publication on the first use only, which is turned into italics. -- Álvaro Herrera

Re: [HACKERS] pg_dumping extensions having sequences with 9.6beta3

Michael, (dropping -general, not sure why that list was included...) * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Wed, Jul 27, 2016 at 8:07 AM, Stephen Frost wrote: > > That'd be great. It's definitely on my list of things to look into, but > > I'm extremely

Re: [HACKERS] "Strong sides of MySQL" talk from PgDay16Russia, translated

On 7/29/16 8:17 AM, Kevin Grittner wrote: On Thu, Jul 28, 2016 at 8:39 PM, Tatsuo Ishii wrote: > BTW, is there any opposite information, i.e. showing the > limitation of MySQL comparing with PostgreSQL? I'm not aware of a general list on the topic, but in reviewing

Re: [HACKERS] Why we lost Uber as a user

* Jim Nasby (jim.na...@bluetreble.com) wrote: > On 7/28/16 10:05 AM, Alex Ignatov wrote: > >>Just curious: what if PostgreSQL supported index that stores "primary > >>key" (or unique key) instead of tids? > > > >You mean IOT like Oracle have? > > IIRC, IOT either stores the table in index order,

Re: [HACKERS] Fix comment in ATExecValidateConstraint

On Mon, Jul 25, 2016 at 4:18 AM, Amit Langote wrote: > The comment seems to have been copied from ATExecAddColumn, which says: > > /* > * If we are told not to recurse, there had better not be any > - * child tables; else the addition would put them out of step.

Re: [HACKERS] Why we lost Uber as a user

On Fri, Jul 29, 2016 at 10:44:29AM -0400, Stephen Frost wrote: > Another thought that was kicking around in my head related to that is if > we could have indexes that only provide page-level information (similar > to BRIN, but maybe a btree) and which also would allow HOT updates. > Those indexes

Re: [HACKERS] sslmode=require fallback

On 7/29/16 11:13 AM, Bruce Momjian wrote: > Yes, I am thinking of a case where Postgres is down but a malevolent > user starts a Postgres server on 5432 to gather passwords. Verifying > against an SSL certificate would avoid this problem, so there is some > value in using SSL on localhost.

Re: [HACKERS] Wrong defeinition of pq_putmessage_noblock since 9.5

Kyotaro HORIGUCHI writes: > At Fri, 29 Jul 2016 12:47:53 +0900, Michael Paquier > wrote in >

Re: [HACKERS] Design for In-Core Logical Replication

On Wed, Jul 20, 2016 at 4:08 AM, Simon Riggs wrote: > In this post, Petr and I present a joint view on a design for how this > should work in-core, based upon our implementation experiences with physical > replication, pglogical and various comments so far. > > Note that

Re: [HACKERS] sslmode=require fallback

On Tue, Jul 19, 2016 at 03:24:26PM -0400, Peter Eisentraut wrote: > On 7/19/16 10:00 AM, Magnus Hagander wrote: > > What could actually be useful there is to explicitly put hostnossl on > > the localhost entries. With the current defaults on the clients, that > > wouldn't break anything, and it

Re: [HACKERS] sslmode=require fallback

On Fri, Jul 29, 2016 at 4:13 PM, Bruce Momjian wrote: > Yes, I am thinking of a case where Postgres is down but a malevolent > user starts a Postgres server on 5432 to gather passwords. Or someone spoofs your DNS lookup, which is an attack that can actually be done remotely in

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: > On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote: > > The following bug has been logged on the website: > > > > Bug reference: 14244 > > Logged by: Thomas Berger > > Email address:

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote: > The following bug has been logged on the website: > > Bug reference: 14244 > Logged by: Thomas Berger > Email address: thomas.ber...@1und1.de > PostgreSQL version: 9.5.3 > Operating system: any >

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Fri, Jul 29, 2016 at 08:18:38PM -0400, Bruce Momjian wrote: > However, that is not the end of the story. Things have moved forward > since 2006 and there is now firm support for either KB or KiB to be > 1024-based units. This blog post explains the current state of prefix > specification: >

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Sat, Jul 30, 2016 at 1:17 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 26, 2016 at 9:27 PM, Michael Paquier >> wrote: >>> While looking at the series of functions pg_get_*, I have noticed as >>> well that

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Hi, On 07/29/2016 01:15 PM, Aleksander Alekseev wrote: Hello Some time ago we discussed an idea of "fast temporary tables": https://www.postgresql.org/message-id/20160301182500.2c81c3dc%40fujitsu In two words the idea is following. PostgreSQL stores information about all relations in

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

2016-07-30 3:47 GMT+02:00 David G. Johnston : > On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: > >> On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote: >> > The following bug has been logged on the website: >> > >> > Bug

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

2016-07-30 1:46 GMT+02:00 Tomas Vondra : > Hi, > > On 07/29/2016 01:15 PM, Aleksander Alekseev wrote: > >> Hello >> >> Some time ago we discussed an idea of "fast temporary tables": >> >> https://www.postgresql.org/message-id/20160301182500.2c81c3dc%40fujitsu >> >>

Re: [HACKERS] Wrong defeinition of pq_putmessage_noblock since 9.5

I wrote: > Kyotaro HORIGUCHI writes: >> Any work in this area is likely 10.0 material at this point. > I'm not really happy with that, since refactoring it again will create > back-patch hazards. But I see that a lot of the mess here was created > in 9.5, which

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Tue, Jul 26, 2016 at 9:27 PM, Michael Paquier wrote: > On Wed, Jul 27, 2016 at 5:11 AM, Robert Haas wrote: >> Committed with minor kibitizing: you don't need an "else" after a >> statement that transfers control out of the function. > >

Re: [HACKERS] pg_dumping extensions having sequences with 9.6beta3

On Wed, Jul 27, 2016 at 2:24 AM, Michael Paquier wrote: > On Wed, Jul 27, 2016 at 8:07 AM, Stephen Frost wrote: >> That'd be great. It's definitely on my list of things to look into, but >> I'm extremely busy this week. I hope to look into it on

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

Robert Haas writes: > On Tue, Jul 26, 2016 at 9:27 PM, Michael Paquier > wrote: >> While looking at the series of functions pg_get_*, I have noticed as >> well that pg_get_userbyid() returns "unknown (OID=%u)" when it does >> not know a user.

Re: [HACKERS] "Strong sides of MySQL" talk from PgDay16Russia, translated

On Fri, Jul 29, 2016 at 5:28 PM, Jim Nasby wrote: > > The way I sum up MySQL vs PG for people that ask is to recount how they > "fixed" the Feb. 31st bug when they released strict mode (something that > they actually called out in the release PR). With strict mode

Re: [HACKERS] to_date_valid()

On 27.07.2016 05:00, Joshua D. Drake wrote: On 07/26/2016 06:25 PM, Peter Eisentraut wrote: On 7/5/16 4:24 AM, Albe Laurenz wrote: But notwithstanding your feeling that you would like your application to break if it makes use of this behaviour, it is a change that might make some people pretty

Re: [HACKERS] Why we lost Uber as a user

* Bruce Momjian (br...@momjian.us) wrote: > On Fri, Jul 29, 2016 at 10:44:29AM -0400, Stephen Frost wrote: > > Another thought that was kicking around in my head related to that is if > > we could have indexes that only provide page-level information (similar > > to BRIN, but maybe a btree) and