Re: PostgreSQL 11 beta1 : regressions failed on OpenBSD with JIT

On Fri, May 25, 2018 at 02:37:52PM +0200, Pierre-Emmanuel André wrote: > On Thu, May 24, 2018 at 01:03:00PM -0700, Andres Freund wrote: > > Hi, > > > > On 2018-05-24 21:47:27 +0200, Pierre-Emmanuel André wrote: > > > Hello, > > > > > > I'm the maintainer of PostgreSQL on OpenBSD. > > > Today I tr

Re: libpq compression

On Tue, Jun 05, 2018 at 06:58:42PM +0300, Konstantin Knizhnik wrote: > I have considered this patch mostly as prototype to estimate efficiency of > libpq protocol compression and compare it with SSL compression. > So I agree with you that there are a lot of things which should be > improved. Cool.

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/06 2:08, Alvaro Herrera wrote: > On 2018-Jun-05, Amit Langote wrote: > >> On 2018/06/05 16:41, Ashutosh Bapat wrote: >>> On Tue, Jun 5, 2018 at 1:07 PM, Amit Langote >>> wrote: On 2018/06/05 1:25, Alvaro Herrera wrote: > In the meantime, my inclination is to fix the documentat

Re: I'd like to discuss scaleout at PGCon

On 5 June 2018 at 17:14, MauMau wrote: > Furthermore, an extra hop and double parsing/planning could matter for > analytic queries, too. For example, SAP HANA boasts of scanning 1 > billion rows in one second. In HANA's scaleout architecture, an > application can connect to any worker node and

Re: I'd like to discuss scaleout at PGCon

On 05.06.2018 20:17, MauMau wrote: From: Merlin Moncure FWIW, Distributed analytical queries is the right market to be in. This is the field in which I work, and this is where the action is at. I am very, very, sure about this. My view is that many of the existing solutions to this problem

Re: Loaded footgun open_datasync on Windows

On Wed, Jun 6, 2018 at 10:18 AM, Michael Paquier wrote: > On Wed, Jun 06, 2018 at 09:58:34AM +0530, Amit Kapila wrote: > > >> It could be > >> risky for existing callers of open() for tool maintainers, or on the > >> contrary people could welcome a wrapper of open() which is > >> concurrent-safe

Re: I'd like to discuss scaleout at PGCon

2018-06-06 10:58 GMT+02:00 Konstantin Knizhnik : > > > On 05.06.2018 20:17, MauMau wrote: > >> From: Merlin Moncure >> >>> FWIW, Distributed analytical queries is the right market to be in. >>> This is the field in which I work, and this is where the action is >>> >> at. >> >>> I am very, very, su

Re: libpq compression

On 06.06.2018 10:53, Michael Paquier wrote: On Tue, Jun 05, 2018 at 06:58:42PM +0300, Konstantin Knizhnik wrote: I have considered this patch mostly as prototype to estimate efficiency of libpq protocol compression and compare it with SSL compression. So I agree with you that there are a lot

Re: Loaded footgun open_datasync on Windows

On Wed, Jun 6, 2018 at 2:39 PM, Amit Kapila wrote: > On Wed, Jun 6, 2018 at 10:18 AM, Michael Paquier > wrote: >> >> On Wed, Jun 06, 2018 at 09:58:34AM +0530, Amit Kapila wrote: >> >> >> It could be >> >> risky for existing callers of open() for tool maintainers, or on the >> >> contrary people c

Re: libpq compression

On 06.06.2018 02:03, Thomas Munro wrote: On Wed, Jun 6, 2018 at 2:06 AM, Konstantin Knizhnik wrote: Thank you for review. Updated version of the patch fixing all reported problems is attached. Small problem on Windows[1]: C:\projects\postgresql\src\include\common/zpq_stream.h(17): error

Re: why partition pruning doesn't work?

On 6 June 2018 at 18:05, Amit Langote wrote: > On 2018/06/06 14:10, David Rowley wrote: >> I then decided that >> I didn't like the way we need to check which params are in the Expr >> each time we call partkey_datum_from_expr. It seems better to prepare >> this in advance when building the prunin

processSQLNamePattern() analog

Hello! I'm working on adding to psql commands to print information about access methods. I ran into the following problem: The command "\dA" (as well as several commands that I write) accept the access method name template. The resulting template is processed by the processSQLNamePattern () fun

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

(2018/05/18 16:33), Etsuro Fujita wrote: Other than pull_var_clause things, the updated version looks good to me, so I'll mark this as Ready for Committer. Since I'm not 100% sure that that is the right way to go, I've been rethinking how to fix this issue. Yet another idea I came up with to

Re: Performance regression with PostgreSQL 11 and partitioning

On Wed, Jun 6, 2018 at 11:27 AM, David Rowley wrote: > > I was trying to be realistic for something we can do to fix v11. It's > probably better to minimise the risky surgery on this code while in > beta. What I proposed was intended to fix a performance regression new > in v11. I'm not sure what

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On Tue, Jun 5, 2018 at 10:38 PM, Alvaro Herrera wrote: > - BEFORE row triggers are not supported I think this is fine. The existing wording suggests that the user creates the triggers on the partitioned table, and that will be supported always, which can lead to problems. With this description,

Re: buildfarm vs code

On 06/05/2018 11:35 PM, Thomas Munro wrote: On Wed, Jun 6, 2018 at 4:09 AM, Andrew Dunstan wrote: At my talk at pgcon last Friday [1] I presented some ideas for how people could run a full buildfarm run against their code, including a 4 line recipe using some Docker recipes I had created. Th

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

On 2018-06-05 17:11:17 -0400, Chapman Flack wrote: > On 06/05/2018 04:57 PM, Andres Freund wrote: > > But we don't really change the > > collation of function invocations per-call. > > Is that true? (Not a rhetorical question; I'm unsure.) Yes, it is at the moment. > Is your argument that the

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

Hi, On 2018-06-06 01:01:49 -0400, Tom Lane wrote: > Andres Freund writes: > > In my understanding FunctionCallInfoData is basically per-call data, > > whereas FmgrInfo is information about the function. It makes some sense > > that ->context is in FunctionCallInfoData, after all it's used for >

Re: buildfarm vs code

On Wed, Jun 6, 2018 at 9:05 AM, Thomas Munro wrote: > On Wed, Jun 6, 2018 at 4:09 AM, Andrew Dunstan > wrote: > > At my talk at pgcon last Friday [1] I presented some ideas for how people > > could run a full buildfarm run against their code, including a 4 line > recipe > > using some Docker rec

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Tue, Jun 5, 2018 at 7:35 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Tue, Jun 5, 2018 at 4:02 PM Andres Freund wrote: > > On 2018-06-05 13:09:08 +0300, Alexander Korotkov wrote: > > > It appears that buffer replacement happening inside relation > > > extension lock is affec

Re: buildfarm vs code

On 06/06/2018 09:16 AM, Amit Kapila wrote: > The second change the recipe makes is to disable the tablespace tests. On > Windows, when running as the Administrator, the application gives up > privilege to such an extent that the tablespace tests fail. Ohh.  I was confused

Re: POC: GROUP BY optimization

On 06/05/2018 07:56 PM, Teodor Sigaev wrote: Thanks for the patch. This (missing) optimization popped-up repeatedly recently, and I was planning to look into it for PG12. So now I don't have to, because you've done all the hard work ;-) You are welcome. Actually one of out customers faced the

Re: Spilling hashed SetOps and aggregates to disk

On 06/05/2018 07:39 PM, David Fetter wrote: On Tue, Jun 05, 2018 at 01:27:01PM -0400, Tom Lane wrote: David Fetter writes: On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote: True. Although not all built in aggregates have those defined. Just out of curiosity, which ones don't

Re: Spilling hashed SetOps and aggregates to disk

Hi, On 2018-06-06 15:58:16 +0200, Tomas Vondra wrote: > The other issue is that serialize/deserialize is only a part of a problem - > you also need to know how to do "combine", and not all aggregates can do > that ... (certainly not in universal way). There are several schemes where only serializ

Re: Spilling hashed SetOps and aggregates to disk

On 06/06/2018 04:01 PM, Andres Freund wrote: Hi, On 2018-06-06 15:58:16 +0200, Tomas Vondra wrote: The other issue is that serialize/deserialize is only a part of a problem - you also need to know how to do "combine", and not all aggregates can do that ... (certainly not in universal way). Th

Re: Spilling hashed SetOps and aggregates to disk

On 2018-06-06 16:06:18 +0200, Tomas Vondra wrote: > On 06/06/2018 04:01 PM, Andres Freund wrote: > > Hi, > > > > On 2018-06-06 15:58:16 +0200, Tomas Vondra wrote: > > > The other issue is that serialize/deserialize is only a part of a problem > > > - > > > you also need to know how to do "combine

Re: buildfarm vs code

Andrew Dunstan writes: > Yeah, what seems quite odd, though, is that when run as an unprivileged > use the tablespace test runs just fine, but when run as a privileged > user it fails. If that's fixable we should fix it :-) I'm curious to know what the failure looks like exactly?

Re: I'd like to discuss scaleout at PGCon

From: Ashutosh Bapat > Keeping OIDs same across the nodes would require extra communication > between nodes to keep track of next OID, dropped OIDs etc. We need to > weigh the time spent in that communication and the time saved during > parsing. If we manage the system catalog for cluster-wide obj

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

On 6/6/18 09:06, Andres Freund wrote: >> It's true that we often abuse fn_extra to hold data that's essentially >> call-site-dependent, but I don't think that's a good reason to push >> collation into FmgrInfo. > FmgrInfo really *is* call-site dependent, no? fn_extra, fn_mcxt, fn_expr > all are. I

Re: pg_replication_slot_advance to return NULL instead of 0/0 if slot not advanced

On 06/06/18 04:04, Michael Paquier wrote: > On Tue, Jun 05, 2018 at 01:00:30PM +0200, Petr Jelinek wrote: >> I didn't say anything about CreateDecodingContext though. I am talking >> about the fact that we then use the same variable as input to >> XLogReadRecord later in the logical slot code pat

Re: PATCH pass PGOPTIONS to pg_regress

On 5/29/18 09:19, Manuel Kniep wrote: > Consider something like this in an extensions makefile: > > ifeq ($(shell test $(VERSION_NUM) -ge 90600; echo $$?),0) > PGOPTIONS+= "--max_parallel_workers_per_gather=0" > endif I think you can probably write this inside your test .sql file using a bit of P

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

Peter Eisentraut writes: > On 6/6/18 09:06, Andres Freund wrote: >> FmgrInfo really *is* call-site dependent, no? fn_extra, fn_mcxt, fn_expr >> all are. I think it's more useful to view the FmgrInfo / >> FunctionCallInfo data split as the separation between per-callsite and >> per-call data. And

Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints

[Re-send; first attempt appears to have hit /dev/null somewhere. My apologies if you get two copies.] I've finally gotten around to rebasing this patch and making the change that was requested, which was: merge the now-would-be-three deferral- related bool columns in various pg_catalog tables int

Re: Scariest patch tournament, PostgreSQL 11 edition

PostgreSQL hackers and community at large, previously I wrote: > In the spirit of the season, the Release Management Team would like to > gather your thoughts on Fear, Risk and Data Corruption for features in > PostgreSQL 11. What patch or patches committed in this cycle do you > think have the h

Re: I'd like to discuss scaleout at PGCon

From: Michael Paquier > Greenplum's orca planner (and Citus?) have such facilities if I recall > correctly, just mentioning that pushing down directly to remote nodes > compiled plans ready for execution exists here and there (that's not the > case of XC/XL). For queries whose planning time is way

Re: commitfest 2018-07

> On Jun 5, 2018, at 1:34 PM, Jonathan S. Katz > wrote: > > >> On Jun 5, 2018, at 10:14 AM, Tom Lane wrote: >> >> Michael Paquier writes: >>> Okay. If we tend toward this direction, I propose to do this switch in >>> two days my time (Thursday afternoon in Tokyo) if there are no >>> object

Re: file cloning in pg_upgrade and CREATE DATABASE

I have made a major revision of this patch. I have removed all the changes to CREATE DATABASE. That was too contentious and we got lost in unrelated details there. The real benefit is for pg_upgrade. Another point was that for pg_upgrade use a user would like to know beforehand whether reflinki

Re: Explain buffers wrong counter with parallel plans

On 2018-May-07, Robert Haas wrote: > On Sat, May 5, 2018 at 8:56 AM, Amit Kapila wrote: > > The reason why I think the current behavior is okay because it is > > coincidental that they were displayed correctly. We have not made any > > effort to percolate it to upper nodes. For ex., before that

Re: Transform for pl/perl

On 2018-May-17, Peter Eisentraut wrote: > The items that are still open from the original email are: > > 2) jsonb scalar values are passed to the plperl function wrapped in not >one, but _two_ layers of references > > 3) jsonb numeric values are passed as perl's NV (floating point) type, >

Re: Possible bug in logical replication.

This thread seems to have died down without any fix being proposed. Simon, you own this open item. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Portability concerns over pq_sendbyte?

On 2018-May-24, Andrew Gierth wrote: > In PG11, pq_sendbyte got changed from taking an int parameter to taking > an int8. > Would it be better for these to take unsigned values, or have unsigned > variants? Do you have an answer to this question? Does anybody else? (My guts tell me it'd be bet

Re: libpq compression

On 05.06.2018 20:06, Peter Eisentraut wrote: On 6/5/18 03:09, Michael Paquier wrote: I just had a quick look at this patch, lured by the smell of your latest messages... And it seems to me that this patch needs a heavy amount of work as presented. There are a couple of things which are not

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On 2018-May-29, Michael Paquier wrote: > On Tue, May 29, 2018 at 10:33:03PM -0400, Heikki Linnakangas wrote: > > Hmm. I think Peter went through this in commits ac3ff8b1d8 and 054e8c6cdb. > > If you got that working now, I suppose we could do that, but I'm actually > > inclined to just stick to th

Re: I'd like to discuss scaleout at PGCon

From: Simon Riggs On 5 June 2018 at 17:14, MauMau wrote: >> Furthermore, an extra hop and double parsing/planning could matter for >> analytic queries, too. For example, SAP HANA boasts of scanning 1 >> billion rows in one second. In HANA's scaleout architecture, an >> application can connect t

Re: commitfest 2018-07

On 06/06/2018 11:57 AM, Jonathan S. Katz wrote: On Jun 5, 2018, at 1:34 PM, Jonathan S. Katz > wrote: On Jun 5, 2018, at 10:14 AM, Tom Lane > wrote: Michael Paquier mailto:mich...@paquier.xyz>> writes: Okay.  If we tend

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

Alvaro Herrera writes: > If SCRAM channel binding is an important aspect to security, and the > older OpenSSL versions will still be around in servers for some time > yet, it seems like it behooves us to go the extra mile and provide an > implementation that works with such existing servers. Look

Re: processSQLNamePattern() analog

Sergey Cherkashin writes: > The command "\dA" (as well as several commands that I write) accept the > access method name template. The resulting template is processed by the > processSQLNamePattern () function, which means that a template with a schema > can be fed to the input. But since the a

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

Hi, On 2018-06-06 11:17:33 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On 6/6/18 09:06, Andres Freund wrote: > >> FmgrInfo really *is* call-site dependent, no? fn_extra, fn_mcxt, fn_expr > >> all are. I think it's more useful to view the FmgrInfo / > >> FunctionCallInfo data split as t

Re: libpq compression

On 06.06.2018 19:33, Konstantin Knizhnik wrote: On 05.06.2018 20:06, Peter Eisentraut wrote: On 6/5/18 03:09, Michael Paquier wrote: I just had a quick look at this patch, lured by the smell of your latest messages...  And it seems to me that this patch needs a heavy amount of work as pre

Re: libpq compression

On 06/06/2018 10:20 AM, Konstantin Knizhnik wrote: Well, psql really allows to specify complete connection string with -d options (although it is not mentioned in help). But still I think that it is inconvenient to require user to write complete connection string to be able to specify compressi

Re: buildfarm vs code

On 06/06/2018 10:24 AM, Tom Lane wrote: Andrew Dunstan writes: Yeah, what seems quite odd, though, is that when run as an unprivileged use the tablespace test runs just fine, but when run as a privileged user it fails. If that's fixable we should fix it :-) I'm curious to know what the fail

Re: buildfarm vs code

Andrew Dunstan writes: > On 06/06/2018 10:24 AM, Tom Lane wrote: >> I'm curious to know what the failure looks like exactly? > [00:07:37] 2018-06-06 17:25:41.662 UTC [1904:7] pg_regress/tablespace > ERROR: could not set permissions on directory > "C:/projects/pg-devel/src/test/regress/testtabl

Re: POC: GROUP BY optimization

problem 2). Index optimization was noticed by me later. But based on your suggested patch's order I split the patch to index and non-index part and second part depends of first one. They touch the same part of code and they could not be independent The way I see it the patch does two differen

Re: I'd like to discuss scaleout at PGCon

On 2018-Jun-06, Ashutosh Bapat wrote: > On Tue, Jun 5, 2018 at 10:04 PM, MauMau wrote: > > From: Ashutosh Bapat > >> In order to normalize parse trees, we need to at least replace > >> various OIDs in parse-tree with something that the foreign server > >> will understand correctly like table name

Pushing down join clauses into subqueries

It would be nice, if we could push down join quals into subqueries. For example: create table small_table (i int); create table big_table (i int, j int); insert into small_table values (1), (2); -- two rows insert into big_table select g/10, g from generate_series(1, 10) g; -- million rows

Re: buildfarm vs code

On 06/06/2018 01:52 PM, Tom Lane wrote: Andrew Dunstan writes: On 06/06/2018 10:24 AM, Tom Lane wrote: I'm curious to know what the failure looks like exactly? [00:07:37] 2018-06-06 17:25:41.662 UTC [1904:7] pg_regress/tablespace ERROR: could not set permissions on directory "C:/projects/

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On 6/6/18 12:37, Alvaro Herrera wrote: > If SCRAM channel binding is an important aspect to security, and the > older OpenSSL versions will still be around in servers for some time > yet, it seems like it behooves us to go the extra mile and provide an > implementation that works with such existing

Re: Bug in either collation docs or code

On 05/06/18 07:10, Melanie Plageman wrote: Hi, I noticed what seems like a bug in collation. This query errors out: SELECT (SELECT 'c' COLLATE "de_DE") > (SELECT 'ç' COLLATE "es_ES"); -- error While this query does not: SELECT 'c' COLLATE "de_DE" > (SELECT 'ç' COLLATE "es_ES"); -- no error I

Re: Transform for pl/perl

On 6/6/18 12:14, Alvaro Herrera wrote: > On 2018-May-17, Peter Eisentraut wrote: > >> The items that are still open from the original email are: >> >> 2) jsonb scalar values are passed to the plperl function wrapped in not >>one, but _two_ layers of references >> >> 3) jsonb numeric values are

Re: libpq compression

On 6/6/18 13:20, Konstantin Knizhnik wrote: > Well, psql really allows to specify complete connection string with -d > options (although it is not mentioned in help). > But still I think that it is inconvenient to require user to write > complete connection string to be able to specify compressio

Re: Spilling hashed SetOps and aggregates to disk

On 06/06/2018 04:11 PM, Andres Freund wrote: > On 2018-06-06 16:06:18 +0200, Tomas Vondra wrote: >> On 06/06/2018 04:01 PM, Andres Freund wrote: >>> Hi, >>> >>> On 2018-06-06 15:58:16 +0200, Tomas Vondra wrote: The other issue is that serialize/deserialize is only a part of a problem - yo

libpq compression

On Wednesday, June 6, 2018, Peter Eisentraut wrote: > On 6/6/18 13:20, Konstantin Knizhnik wrote: > > Well, psql really allows to specify complete connection string with -d > > options (although it is not mentioned in help). > > But still I think that it is inconvenient to require user to write >

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

TLS 1.3, (which is currently in a draft state, but is theoretically being finalized soon) does not support the TLS channel binding algorithms [1]. >From talking with one of the people working on the TLS 1.3 standard, tls-unique is seen as particularly problematic. There's some discussion on the IET

Re: SCRAM with channel binding downgrade attack

Aren't we attacking this on the wrong level? We are here attempting to prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not preventing a SCRAM-SHA-256-PLUS -> anything-else downgrade. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Sup

Re: SCRAM with channel binding downgrade attack

On 06/06/18 23:20, Peter Eisentraut wrote: Aren't we attacking this on the wrong level? We are here attempting to prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not preventing a SCRAM-SHA-256-PLUS -> anything-else downgrade. The latest patch does prevent that, too. That wa

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

> "Andres" == Andres Freund writes: Andres> I think it's not unreasonable to think of it that way, but it's Andres> really not how it is used today. In pretty much all cases the Andres> collation is known and determined at the time fmgr_info() is Andres> called (we also commonly reuse Fun

Re: SCRAM with channel binding downgrade attack

On 6/6/18 16:26, Heikki Linnakangas wrote: > On 06/06/18 23:20, Peter Eisentraut wrote: >> Aren't we attacking this on the wrong level? We are here attempting to >> prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not >> preventing a SCRAM-SHA-256-PLUS -> anything-else downgrade

Re: POC: GROUP BY optimization

On 06/06/2018 08:04 PM, Teodor Sigaev wrote: > >>> problem 2). Index optimization was noticed by me later. But based on >>> your suggested patch's order I split the patch to index and non-index >>> part and second part depends of first one. They touch the same part >>> of code and they could not b

Re: SCRAM with channel binding downgrade attack

On 05/06/18 09:41, Michael Paquier wrote: On Sat, Jun 02, 2018 at 01:08:56PM -0400, Heikki Linnakangas wrote: On 28/05/18 15:08, Michael Paquier wrote: On Mon, May 28, 2018 at 12:26:37PM +0300, Heikki Linnakangas wrote: + printfPQExpBuffer(&conn->errorMessage, +libpq_gettext("channel bindi

Re: SCRAM with channel binding downgrade attack

On 06/06/18 23:31, Peter Eisentraut wrote: On 6/6/18 16:26, Heikki Linnakangas wrote: On 06/06/18 23:20, Peter Eisentraut wrote: Aren't we attacking this on the wrong level? We are here attempting to prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not preventing a SCRAM-SHA

Re: Needless additional partition check in INSERT?

On 2018-May-10, David Rowley wrote: > Yeah, the comments do need work. In order to make it a bit easier to > document I changed the way that check_partition_constr is set. This is > now done with an if/else if/else clause for both COPY and INSERT. > > Hopefully, that's easier to understand and pr

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Wed, Jun 06, 2018 at 01:16:11PM -0700, Steven Fackler wrote: Thanks for the pointers, Steven. You should avoid top-posting on this list, this is not the style used on the Postgres lists. > TLS 1.3, (which is currently in a draft state, but is theoretically being > finalized soon) does not sup

Re: POC: GROUP BY optimization

On Wed, Jun 6, 2018 at 5:43 PM Tomas Vondra wrote: > > For example, it seems to disregard that different data types have > different comparison costs. For example comparing bytea will be far > more expensive compared to int4, so it may be much more efficient to > compare int4 c

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Wed, Jun 6, 2018 at 2:21 PM Michael Paquier wrote: Thanks for the pointers, Steven. You should avoid top-posting on this > list, this is not the style used on the Postgres lists. > Ah sorry about that! Hopefully this looks better. > Does this mean that tls-server-end-point goes into unsupp

Re: POC: GROUP BY optimization

On 06/06/2018 11:22 PM, Claudio Freire wrote: > On Wed, Jun 6, 2018 at 5:43 PM Tomas Vondra > wrote: >> >> For example, it seems to disregard that different data types have >> different comparison costs. For example comparing bytea will be far >> more expensive compared to int4, so it

Re: SCRAM with channel binding downgrade attack

On Wed, Jun 06, 2018 at 11:53:06PM +0300, Heikki Linnakangas wrote: > That would certainly be good. We've always had that problem, even with md5 > -> plaintext password downgrade, and it would be nice to fix it. It's quite > late in the release cycle already, do you think we should address that now

Re: POC: GROUP BY optimization

On Wed, Jun 6, 2018 at 6:57 PM Tomas Vondra wrote: > > On 06/06/2018 11:22 PM, Claudio Freire wrote: > > On Wed, Jun 6, 2018 at 5:43 PM Tomas Vondra > > As such, estimating sort performance correctly in the various plan > > variants being considered seems to be a very central aspect of it. > > > >

Re: POC: GROUP BY optimization

On Wed, Jun 6, 2018 at 7:18 PM Claudio Freire wrote: > > > Comparison cost can be approximated probabilistically as: > > > > > > cost_comp = sum(cost_op_n * (1.0 / ndistinct(col_1_to_n))) > > > > > > Where cost_op_n is the cost of the comparison function for column N, > > > and ndistinct(col_1_to_

Re: I'd like to discuss scaleout at PGCon

From: Alvaro Herrera > Maybe an easy (hah) thing to do is use 2PC for DDL, agree on a OID > that's free on every node, then create the object in all servers at the > same time. We currently use the system-wide OID generator to assign the > OID, but seems an easy thing to change (much harder is to

Re: I'd like to discuss scaleout at PGCon

From: Alvaro Herrera > Maybe an easy (hah) thing to do is use 2PC for DDL, agree on a OID > that's free on every node, then create the object in all servers at the > same time. We currently use the system-wide OID generator to assign the > OID, but seems an easy thing to change (much harder is to

Re: POC: GROUP BY optimization

On 06/07/2018 12:18 AM, Claudio Freire wrote: > On Wed, Jun 6, 2018 at 6:57 PM Tomas Vondra > wrote: >> >> On 06/06/2018 11:22 PM, Claudio Freire wrote: >>> On Wed, Jun 6, 2018 at 5:43 PM Tomas Vondra >>> As such, estimating sort performance correctly in the various plan >>> variants being consi

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

Hi, On 2018-06-06 21:25:14 +0100, Andrew Gierth wrote: > > "Andres" == Andres Freund writes: > > Andres> I think it's not unreasonable to think of it that way, but it's > Andres> really not how it is used today. In pretty much all cases the > Andres> collation is known and determined at t

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

Andres Freund writes: > On 2018-06-06 21:25:14 +0100, Andrew Gierth wrote: >> The obvious case which is not one of those "pretty much all cases" is >> where DirectFunctionCallN[Coll] is used - which turns out to be not all >> that unusual. > There the callsite just lives for just one call, I don'

Re: POC: GROUP BY optimization

On Wed, Jun 6, 2018 at 8:06 PM Tomas Vondra wrote: > >>> Comparison cost can be approximated probabilistically as: > >>> > >>> cost_comp = sum(cost_op_n * (1.0 / ndistinct(col_1_to_n))) > >>> > >>> Where cost_op_n is the cost of the comparison function for column N, > >>> and ndistinct(col_1_to_n)

Re: Needless additional partition check in INSERT?

On 7 June 2018 at 09:08, Alvaro Herrera wrote: > I wonder if we should create a new small function that takes the two > resultRelInfos and returns the correct boolean --maybe something like > ExecConstraintsPartConstrNeedsRecheck()-- and then the smarts are in a > single place and we diminish the

Re: Spilling hashed SetOps and aggregates to disk

On 7 June 2018 at 08:11, Tomas Vondra wrote: > On 06/06/2018 04:11 PM, Andres Freund wrote: >> Consider e.g. a scheme where we'd switch from hashed aggregation to >> sorted aggregation due to memory limits, but already have a number of >> transition values in the hash table. Whenever the size of t

Re: commitfest 2018-07

On Wed, Jun 06, 2018 at 12:40:40PM -0400, Andrew Dunstan wrote: > I'll volunteer for CFM, which seems appropriate since I was one of the > supporters of having an extra CF. I don't mind helping out either. There are many patches to handle. -- Michael signature.asc Description: PGP signature

Re: Spilling hashed SetOps and aggregates to disk

On 06/07/2018 02:11 AM, David Rowley wrote: > On 7 June 2018 at 08:11, Tomas Vondra wrote: >> On 06/06/2018 04:11 PM, Andres Freund wrote: >>> Consider e.g. a scheme where we'd switch from hashed aggregation to >>> sorted aggregation due to memory limits, but already have a number of >>> transi

Re: Spilling hashed SetOps and aggregates to disk

On 2018-06-07 12:11:37 +1200, David Rowley wrote: > On 7 June 2018 at 08:11, Tomas Vondra wrote: > > On 06/06/2018 04:11 PM, Andres Freund wrote: > >> Consider e.g. a scheme where we'd switch from hashed aggregation to > >> sorted aggregation due to memory limits, but already have a number of > >>

Re: Spilling hashed SetOps and aggregates to disk

On 2018-06-06 17:17:52 -0700, Andres Freund wrote: > On 2018-06-07 12:11:37 +1200, David Rowley wrote: > > On 7 June 2018 at 08:11, Tomas Vondra wrote: > > > On 06/06/2018 04:11 PM, Andres Freund wrote: > > >> Consider e.g. a scheme where we'd switch from hashed aggregation to > > >> sorted aggreg

Re: Spilling hashed SetOps and aggregates to disk

On 6 June 2018 at 01:17, David Rowley wrote: > On 6 June 2018 at 01:09, Andres Freund wrote: >> On 2018-06-06 01:06:39 +1200, David Rowley wrote: >>> My concern is that only accounting memory for the group and not the >>> state is only solving half the problem. It might be fine for >>> aggregates

Re: pg_replication_slot_advance to return NULL instead of 0/0 if slot not advanced

On Wed, Jun 06, 2018 at 04:57:22PM +0200, Petr Jelinek wrote: > I think the only thing to note about the patches from my side is that we > probably don't want to default to restart_lsn for the > pg_logical_replication_slot_advance() return value (when nothing was > done) but rather the confirmed_ls

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/06 20:51, Ashutosh Bapat wrote: > The existing wording suggests that the user > creates the triggers on the partitioned table, and that will be > supported always, which can lead to problems. Do you mean the following wording "BEFORE ROW triggers, if necessary, must be defined on indiv

Re: libpq compression

On 7 June 2018 at 04:01, Peter Eisentraut wrote: > On 6/6/18 13:20, Konstantin Knizhnik wrote: > > Well, psql really allows to specify complete connection string with -d > > options (although it is not mentioned in help). > > But still I think that it is inconvenient to require user to write > >

Re: why partition pruning doesn't work?

On 2018/06/06 18:52, David Rowley wrote: > On 6 June 2018 at 18:05, Amit Langote wrote: >> On 2018/06/06 14:10, David Rowley wrote: >>> I then decided that >>> I didn't like the way we need to check which params are in the Expr >>> each time we call partkey_datum_from_expr. It seems better to prep

Re: commitfest 2018-07

> On Jun 6, 2018, at 8:14 PM, Michael Paquier wrote: > > On Wed, Jun 06, 2018 at 12:40:40PM -0400, Andrew Dunstan wrote: >> I'll volunteer for CFM, which seems appropriate since I was one of the >> supporters of having an extra CF. > > I don't mind helping out either. There are many patches t

Re: why partition pruning doesn't work?

On 7 June 2018 at 14:51, Amit Langote wrote: > Thanks David. This one looks good. I also like it that hasparamlessexprs > is no longer determined and set in the planner. Thanks for checking it. > I checked what happens with the cases that Ashutosh complained about > upthread and seems that the

Re: Loaded footgun open_datasync on Windows

On Wed, Jun 6, 2018 at 3:06 PM, Kuntal Ghosh wrote: > On Wed, Jun 6, 2018 at 2:39 PM, Amit Kapila > wrote: > > On Wed, Jun 6, 2018 at 10:18 AM, Michael Paquier > > wrote: > >> > >> On Wed, Jun 06, 2018 at 09:58:34AM +0530, Amit Kapila wrote: > >> > >> >> It could be > >> >> risky for existing c

Re: Needless additional partition check in INSERT?

On 2018-Jun-07, David Rowley wrote: > Hi Alvaro, > > Thanks for looking at this. I thought it was strange to pass in both > resultRelInfos. I ended up just making the 2nd param a bool to > indicate of tuple routing was used. Good call. > I'm personally not really for or against having the funct

Re: Needless additional partition check in INSERT?

On 2018/06/07 12:57, Alvaro Herrera wrote: > On 2018-Jun-07, David Rowley wrote: >> I'm personally not really for or against having the function. I agree >> that it's slightly weird, but anyway, here's the patch. I'll leave it >> up to you to which one you prefer, v3 or v4. > > Hm I was thinking t

  1   2   >