Re: Generating partitioning tuple conversion maps faster

On Mon, Jun 25, 2018 at 10:57 AM Amit Langote wrote: > > On 2018/06/25 14:12, amul sul wrote: > > On Mon, Jun 25, 2018 at 10:30 AM David Rowley > > wrote: > >> > > [...] > >> Given the small size of this patch. I think it's a good candidate for > >> the July 'fest. > >> > > > > Just a different

Re: Generating partitioning tuple conversion maps faster

On 2018/06/25 14:12, amul sul wrote: > On Mon, Jun 25, 2018 at 10:30 AM David Rowley > wrote: >> > [...] >> Given the small size of this patch. I think it's a good candidate for >> the July 'fest. >> > > Just a different thought, how about having flag array something like > needed_tuple_conv? >

Re: Generating partitioning tuple conversion maps faster

On Mon, Jun 25, 2018 at 10:30 AM David Rowley wrote: > [...] > Given the small size of this patch. I think it's a good candidate for > the July 'fest. > Just a different thought, how about having flag array something like needed_tuple_conv? While loading partdesc, we could calculate that the

Generating partitioning tuple conversion maps faster

Hi, The code in convert_tuples_by_name_map() could be made a bit smarter to speed up the search for the column with the same name by first looking at the same attnum in the other relation rather than starting the search from the first attnum each time. I imagine most people are going to create

Re: effect of JIT tuple deform?

2018-06-25 5:41 GMT+02:00 Andres Freund : > On 2018-06-25 05:32:37 +0200, Pavel Stehule wrote: > > 2018-06-24 22:32 GMT+02:00 Dmitry Dolgov <9erthali...@gmail.com>: > > > > > > On 23 June 2018 at 08:47, Pavel Stehule > wrote: > > > > > > > > > > > > 2018-06-23 8:35 GMT+02:00 Pavel Stehule : > >

Re: effect of JIT tuple deform?

On 2018-06-25 05:32:37 +0200, Pavel Stehule wrote: > 2018-06-24 22:32 GMT+02:00 Dmitry Dolgov <9erthali...@gmail.com>: > > > > On 23 June 2018 at 08:47, Pavel Stehule wrote: > > > > > > > > > 2018-06-23 8:35 GMT+02:00 Pavel Stehule : > > >> > > >> Hi > > >> > > >> I try to measure effect of JIT

Re: Is PG built on any C compilers where int division floors?

Chapman Flack writes: > C99 finally pinned down what / does on signed ints, truncating toward zero. > Before that, it could truncate toward zero, or floor toward -inf. > Is PostgreSQL built on any compilers/platforms that have the floor > behavior? I'm not sure if we still have any buildfarm

Re: bug with expression index on partition

On 2018/06/23 5:54, Alvaro Herrera wrote: > On 2018-Jun-21, Amit Langote wrote: > >> On 2018/06/21 15:35, Amit Langote wrote: >>> So, CompareIndexInfo and generateClonedIndexStmt are both doing the right >>> thing, but DefineIndex is not. Attached is a patch to fix DefineIndex so >>> that it

Incorrect fsync handling in pg_basebackup's tar_finish

Hi all, I was just looking at the code of pg_basebackup, and noticed that we don't actually check if the two last empty blocks of any tar file produced are correctly fsync'd or not: @@ -957,7 +957,10 @@ tar_finish(void) /* sync the empty blocks as well, since they're after the last file */ if

Is PG built on any C compilers where int division floors?

C99 finally pinned down what / does on signed ints, truncating toward zero. Before that, it could truncate toward zero, or floor toward -inf. Is PostgreSQL built on any compilers/platforms that have the floor behavior? -Chap

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

On Tue, Jun 19, 2018 at 09:19:40AM +0900, Michael Paquier wrote: > As Peter and Heikki have worked as well on all those features with me, > are there any objection to discard this open item? I looked again at > the patch this morning and it is true that OpenSSL's history makes > things harder, so

Re: postgresql_fdw doesn't handle defaults correctly

Hi. On 2018/06/24 2:23, Pavel Stehule wrote: > Hi > > I have a table boo > > create table boo(id serial primary key, inserted date default current_date, > v varchar); > > I imported this table via simple > > IMPORT FOREIGN SCHEMA public FROM SERVER foreign_server INTO public; It seems you

Re: Incorrect errno used with %m for backend code

On Sun, Jun 24, 2018 at 09:23:50PM +0900, Michael Paquier wrote: > On Sun, Jun 24, 2018 at 09:22:01AM +0530, Ashutosh Sharma wrote: >> Okay, I too had a quick look into the source code to see if there are >> still some places where we could have missed to set an errno to ENOSPC >> in case of write

Re: PATCH: backtraces for error messages

On 21 June 2018 at 19:09, Kyotaro HORIGUCHI wrote: I think this for assertion failure is no problem but I'm not sure > for other cases. I think it's pretty strongly desirable for PANIC. > We could set proper context description or other > additional information in error messages before just

Re: WIP: BRIN multi-range indexes

On 06/25/2018 12:31 AM, Tomas Vondra wrote: > On 06/24/2018 11:39 PM, Thomas Munro wrote: >> On Sun, Jun 24, 2018 at 2:01 PM, Tomas Vondra >> wrote: >>> Attached is rebased version of this BRIN patch series, fixing mostly the >>> breakage due to 372728b0 (aka initial-catalog-data format

Re: do I correctly understand these date/time data types?

On Sun, Jun 24, 2018 at 05:13:38PM -0400, Chapman Flack wrote: > Checking my understanding as in $subject: > > A TIMESTAMP WITH TIME ZONE has had its specified time zone used at the point > of entry to convert it to Z time, and then discarded. If I have to map one > of these to a

Re: WIP: BRIN multi-range indexes

On 06/24/2018 11:39 PM, Thomas Munro wrote: > On Sun, Jun 24, 2018 at 2:01 PM, Tomas Vondra > wrote: >> Attached is rebased version of this BRIN patch series, fixing mostly the >> breakage due to 372728b0 (aka initial-catalog-data format changes). As >> 2018-07 CF is meant for almost-ready

Re: Invisible Indexes

On Sun, Jun 24, 2018 at 09:59:15AM -0400, Tom Lane wrote: > Andrew Dunstan writes: > > A major downside to a GUC is that you have to be aware of the current > > setting, since we're not going to have one settoing for each invisible > > index. Doing it at the SQL level you can treat each index

Re: WIP: BRIN multi-range indexes

On Sun, Jun 24, 2018 at 2:01 PM, Tomas Vondra wrote: > Attached is rebased version of this BRIN patch series, fixing mostly the > breakage due to 372728b0 (aka initial-catalog-data format changes). As > 2018-07 CF is meant for almost-ready patches, this is more a 2018-09 > material. But perhaps

Re: comma to delimit fractional seconds

Hi! Thanks for the reply. Consensus:         Would anyone be likely to use this?  I've never heard of it before.         And I haven't found any other mention of it other than the TODO list.         So it comes down to risk vs standards compliance. Breakage:   I don't think there is likely to

do I correctly understand these date/time data types?

Checking my understanding as in $subject: A TIMESTAMP WITH TIME ZONE has had its specified time zone used at the point of entry to convert it to Z time, and then discarded. If I have to map one of these to a date/time-with-time-zone datatype in another language, I may as well unconditionally map

Re: effect of JIT tuple deform?

Hi, On 2018-06-24 22:32:07 +0200, Dmitry Dolgov wrote: > `perf diff` indeed shows that in the first case (with the 4M rows dataset) the > jitted version has some noticeable delta for one call, and unfortunately so > far > I couldn't figure out which one exactly because of JIT (btw, who can

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

Hi all, Attached is a rebased version of this patch series, mostly just fixing the breakage caused by reworked format of initial catalog data. Aside from that, the MCV building now adopts the logic introduced by commit b5db1d93d2 for single-column MCV lists. The new algorithm seems pretty good

Removing obsolete comment block at the top of nbtsort.c.

nbtsort.c has a comment block from the Berkeley days that reads: * This code is moderately slow (~10% slower) compared to the regular * btree (insertion) build code on sorted or well-clustered data. On * random data, however, the insertion build code is unusable -- the * difference on a 60MB

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

On 24/06/18 18:49, Dave Cramer wrote: On 29 May 2018 at 22:48, 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

Re: New GUC to sample log queries

On 24/06/18 13:22, Adrien Nayrat wrote: > Attached third version of the patch with documentation. Hi. I'm reviewing this. > exceeded = (log_min_duration_statement == 0 || > (log_min_duration_statement > 0 && >

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

On 29 May 2018 at 22:48, 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

Re: utilities to rebuild commit logs from wal

On Sun, Jun 24, 2018 at 5:53 AM Bruce Momjian wrote: > On Fri, Jun 22, 2018 at 10:49:58AM +0200, Chris Travers wrote: > > Before we reinvent the wheel here, does anyone know of utilities to build > > commit logs from wal segments? Or even to just fill with commits? > > > > I figure it is worth

Re: Desirability of client-side expressions in psql?

2018-06-24 16:13 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > This is a discussion without actual patch intended for pg12, to be added to CF 2018-09. The expected end result is either "returned with feedback", meaning proceed to send some big patch(es), or "rejected", meaning the

Re: Desirability of client-side expressions in psql?

Hello Pavel, This is a discussion without actual patch intended for pg12, to be added to CF 2018-09. The expected end result is either "returned with feedback", meaning proceed to send some big patch(es), or "rejected", meaning the project does not want this, no point in submitting something.

Re: Invisible Indexes

Andrew Dunstan writes: > A major downside to a GUC is that you have to be aware of the current > setting, since we're not going to have one settoing for each invisible > index. Doing it at the SQL level you can treat each index separately. A > GUC will actually involve more code, I suspect.

Re: Concurrency bug in UPDATE of partition-key

On Sat, Jun 23, 2018 at 8:25 PM, Alvaro Herrera wrote: > Would you wait a little bit before pushing this? > Sure. > I'd like to give this > a read too. > That would be great. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com

Re: Invisible Indexes

On 06/19/2018 02:05 PM, Robert Haas wrote: On Mon, Jun 18, 2018 at 6:12 PM, Tom Lane wrote: Peter Geoghegan writes: On Mon, Jun 18, 2018 at 2:57 PM, Tom Lane wrote: I think the actually desirable way to handle this sort of thing is through an "index advisor" sort of plugin, which can