Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Tue, Sep 6, 2016 at 8:28 PM, Peter Geoghegan wrote: >> In the meanwhile, I'll go and do some perf testing. >> >> Assuming the speedup is realized during testing, LGTM. > > Thanks. I suggest spending at least as much time on unsympathetic > cases (e.g., only 2 or 3 tapes must

Re: [HACKERS] CF app and patch series

Craig Ringer wrote: > Hi all > > Now that it's becoming more common to post patch series, not just > standalone patches, it might be worth looking at how the CF app can > help manage them. > > Any ideas? I agree that we don't consider this case at all currently and that it's causing some pain.

Re: [HACKERS] Optimization for lazy_scan_heap

On Thu, Sep 8, 2016 at 11:27 PM, Jim Nasby wrote: > On 9/8/16 3:03 AM, Masahiko Sawada wrote: >> >> Current manual vacuum doesn't output how may all_frozen pages we >> skipped according to visibility map. >> That's why I attached 0001 patch which makes the manual vacuum

Re: [HACKERS] to_date_valid()

On 8/15/16 7:33 AM, Andreas 'ads' Scherbaum wrote: > postgres=# SELECT to_date('2011 12 18', ' MM DD'); >to_date > > 2011-12-08 > (1 row) > > > That is from the regression tests, and obviously handles the date > transformation wrong. My attempt catches this, because I

Re: [HACKERS] ICU integration

Peter Eisentraut writes: > On 9/6/16 1:40 PM, Doug Doole wrote: >> We carried the ICU version numbers around on our collation and locale >> IDs (such as fr_FR%icu36) . The database would load multiple versions of >> the ICU library so that something created with

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Thu, Sep 8, 2016 at 11:54 AM, Pavan Deolasee wrote: > For example, for a table with 60 bytes wide tuple (including 24 byte > header), each page can approximately have 8192/60 = 136 tuples. Say we > provision for 136*2 = 272 bits per page i.e. 34 bytes per page for the

Re: [HACKERS] Optimization for lazy_scan_heap

On Thu, Sep 8, 2016 at 4:03 AM, Masahiko Sawada wrote: > On Wed, Sep 7, 2016 at 4:11 PM, Simon Riggs wrote: >> On 7 September 2016 at 04:13, Masahiko Sawada wrote: >> >>> Since current HEAD could scan visibility map twice, the

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 7, 2016 at 10:18 PM, Claudio Freire wrote: > On Wed, Sep 7, 2016 at 12:12 PM, Greg Stark wrote: > > On Wed, Sep 7, 2016 at 1:45 PM, Simon Riggs > wrote: > >> On 6 September 2016 at 19:59, Tom Lane

Re: [HACKERS] Logical Replication WIP

Hi, On 07/09/16 14:10, Erik Rijkers wrote: On 2016-08-31 22:51, Petr Jelinek wrote: and one more version with bug fixes, improved code docs and couple I am not able to get the replication to work. Would you (or anyone) be so kind to point out what I am doing wrong? Patches applied,

Re: [HACKERS] Patch: Implement failover on libpq connect level.

> Hello, Victor. > > > I'm sending new version of patch. > > > > I've replaced readonly option with target_server_type (with JDBC > > compatibility alias targetServerType), > > > > use logic of setting defaults based on number of hosts in the connect > > string instead of complicated condition

Re: [HACKERS] Patch: Implement failover on libpq connect level.

Hello, Victor. > I'm sending new version of patch. > > I've replaced readonly option with target_server_type (with JDBC > compatibility alias targetServerType), > > use logic of setting defaults based on number of hosts in the connect > string instead of complicated condition in the state

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On 9/8/16 3:48 AM, Masahiko Sawada wrote: If we replaced dead_tuples with an array-of-array, isn't there negative performance impact for lazy_tid_reap()? As chunk is added, that performance would be decrease. Yes, it certainly would, as you'd have to do 2 binary searches. I'm not sure how

Re: [HACKERS] Optimization for lazy_scan_heap

On 9/8/16 3:03 AM, Masahiko Sawada wrote: Current manual vacuum doesn't output how may all_frozen pages we skipped according to visibility map. That's why I attached 0001 patch which makes the manual vacuum emit such information. I think we should add that, and info about all-frozen skips,

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

Thank you for comments. >But there's a function in startup.c which might be the ideal location >or the check, as it looks like the one and only place where the >autocommit flag actually changes: >static void >autocommit_hook(const char *newval) Thank you for pointing out this. This indeed is

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

Dilip Kumar writes: > On Thu, Sep 8, 2016 at 2:23 AM, Tom Lane wrote: >> In the case of record_in, it seems like it'd be easy enough to use >> lookup_rowtype_tupdesc_noerror() instead of lookup_rowtype_tupdesc() >> and then throw a user-facing error

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

Michael Paquier writes: > On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander wrote: >> Pretty sure this goes back to *our* XML support requiring both. As in you >> couldn't turn on/off xslt independently, so the "xml requires xslt" comment >> is that

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Thu, Sep 8, 2016 at 2:53 PM, Michael Paquier wrote: > On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander > wrote: > > Pretty sure this goes back to *our* XML support requiring both. As in you > > couldn't turn on/off xslt independently, so the

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander wrote: > Pretty sure this goes back to *our* XML support requiring both. As in you > couldn't turn on/off xslt independently, so the "xml requires xslt" comment > is that *our* xml support required both. > > This may definitely

Re: [HACKERS] Sample configuration files

Vik Fearing writes: > I noticed that this patch has been marked Waiting on Author with no > comment. Peter, what more should I be doing right now while waiting for > Martín's review? FWIW, I agree with the upthread misgivings about whether this is actually a useful effort.

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Thu, Sep 8, 2016 at 9:27 PM, Tom Lane wrote: > Michael Paquier writes: >> But I don't understand the reason behind such a restriction to be >> honest because libxml2 does not depend on libxslt. The contrary is >> true: libxslt needs libxml2. > >

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Thu, Sep 8, 2016 at 2:27 PM, Tom Lane wrote: > Michael Paquier writes: > > But I don't understand the reason behind such a restriction to be > > honest because libxml2 does not depend on libxslt. The contrary is > > true: libxslt needs libxml2.

Re: [HACKERS] Declarative partitioning - another take

On Wed, Sep 7, 2016 at 3:58 PM, Amit Langote wrote: > > Hi, > > On 2016/09/07 17:56, Rajkumar Raghuwanshi wrote: > > Hi, > > > > I have a query regarding list partitioning, > > > > For example if I want to store employee data in a table, with "IT" dept > > employee

Re: [HACKERS] GiST penalty functions [PoC]

Excuse me for intervention. It depends. For instance, i run PostgreSQL on the modern MIPS CPU, which does not have sqrt support. But you are right, it is supported in most cases. And if execution speed of this very fuction is of concern, sqrtf(x) should be used instead of sqrt(x). Despite this,

Re: [HACKERS] Suggestions for first contribution?

On Wed, Sep 7, 2016 at 10:44 AM, Stas Kelvich wrote: > There is also a list of projects for google summer of code: > https://wiki.postgresql.org/wiki/GSoC_2016 > > That topics expected to be doable by a newcomer during several months. It is > also slightly > outdated,

Re: [HACKERS] Suggestions for first contribution?

On Wed, Sep 7, 2016 at 10:34 AM, Yury Zhuravlev wrote: > Christian Convey wrote: >> >> Yury doesn't seem to need help >> with CMake > > Hello. > I am sorry that the only answer is now. > I need help but with write CMake code: > 1. Make ecpg tests > 2. Make MinGW/Msys

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

Michael Paquier writes: > But I don't understand the reason behind such a restriction to be > honest because libxml2 does not depend on libxslt. The contrary is > true: libxslt needs libxml2. Right. > Note as well that libxml2 does depend on ICONV though. Hm, is that

Re: [HACKERS] Suggestions for first contribution?

On Wed, Sep 7, 2016 at 10:14 AM, Aleksander Alekseev wrote: > Here is another idea for a contribution - refactoring. > > Currently there are a lot of procedures in PostgreSQL code that > definitely don't fit on one screen (i.e. ~50 lines). Also many files are > larger

Re: [HACKERS] GiST penalty functions [PoC]

>BTW, would someone explain to me why using a float here will not fail >catastrophically for inputs outside the range of float? Indeed, it will. And that's one of the reason I'm considering advancing GiST API instead of advancing extensions. It won't crash, but will produce terrible index, not

Re: [HACKERS] \timing interval

2016-09-08 13:10 GMT+02:00 Craig Ringer : > On 4 Sep. 2016 3:36 am, "Tom Lane" wrote: > > > > > After further thought I concluded that not providing any labeling of > > days is a bad idea. > > Yeah. I think labeling days is definitely good. I'm

Re: [HACKERS] GiST penalty functions [PoC]

Heikki Linnakangas writes: > BTW, I would be OK with the bit-twiddling hack, if we had an autoconf > check for IEEE 754 floats, and a graceful fallback for other systems. I would still object to the version submitted, on the grounds of the compiler warnings it causes.

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Tue, 6 Sep 2016 07:58:28 +0530 Mithun Cy wrote: > On Mon, Sep 5, 2016 at 4:33 PM, Aleksander Alekseev < > a.aleks...@postgrespro.ru> wrote: > >After a brief examination I've found following ways to improve the > >patch. > Adding to above comments. > I'm sending

Re: [HACKERS] \timing interval

On 4 Sep. 2016 3:36 am, "Tom Lane" wrote: > > After further thought I concluded that not providing any labeling of > days is a bad idea. Yeah. I think labeling days is definitely good. I'm glad you changed that. Personally I'd like to trim milliseconds when dealing with

Re: [HACKERS] High-CPU consumption on information_schema (only) query

On 8 Sep. 2016 7:38 am, "Robins Tharakan" wrote: > > Hi, > > An SQL (with only information_schema related JOINS) when triggered, runs with max CPU (and never ends - killed after 2 days). > - It runs similarly (very slow) on a replicated server that acts as a read-only slave. >

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

On 2016/09/07 13:21, Ashutosh Bapat wrote: * with the patch: postgres=# explain verbose delete from ft1 using ft2 where ft1.a = ft2.a; QUERY PLAN

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/06 22:07, Ashutosh Bapat wrote: On Fri, Sep 2, 2016 at 3:55 PM, Etsuro Fujita > wrote: On 2016/08/22 15:49, Ashutosh Bapat wrote: 1. deparsePlaceHolderVar looks odd - each of the deparse* function

Re: [HACKERS] Bug in two-phase transaction recovery

On 8 September 2016 at 07:43, Michael Paquier wrote: > On Wed, Sep 7, 2016 at 10:48 PM, Stas Kelvich > wrote: >> Some time ago two-phase state file format was changed to have variable size >> GID, >> but several places that read that files

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

On Thu, Sep 8, 2016 at 2:23 AM, Tom Lane wrote: > I really don't like this solution. Changing this one function, out of the > dozens just like it in lsyscache.c, seems utterly random and arbitrary. > > I'm actually not especially convinced that passing domain_in a random >

Re: [HACKERS] [PATCH] Alter or rename enum value

> Given that you are now familiar with the internals of how enums are > implemented would it be possible to continue the work and add the "ALTER > TYPE DROP VALUE " command? I was thinking to try developing it, but I would be more than happy to help by testing and reviewing, if someone else

Re: [HACKERS] Bug in two-phase transaction recovery

On Thu, Sep 8, 2016 at 12:13 PM, Michael Paquier wrote: > On Wed, Sep 7, 2016 at 10:48 PM, Stas Kelvich > wrote: > > Some time ago two-phase state file format was changed to have variable > size GID, > > but several places that read that

Re: [HACKERS] Stopping logical replication protocol

On 7 September 2016 at 15:44, Vladimir Gordiychuk wrote: > Fixed patch in attach. It'd helpful if you summarize the changes made when posting revisions. >> * There are no tests. I don't see any really simple way to test this, >> though. > > I will be grateful if you specify

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Wed, Sep 7, 2016 at 4:03 AM, Josh Berkus wrote: > On 08/29/2016 06:52 AM, Fujii Masao wrote: >> Also I like the following Simon's idea. >> >> https://www.postgresql.org/message-id/canp8+jlhfbvv_pw6grasnupw+bdk5dctu7gwpnap-+-zwvk...@mail.gmail.com >> ---

Re: [HACKERS] [COMMITTERS] pgsql: Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

On 7 September 2016 at 14:58, Tom Lane wrote: >> That may not be perceived as a "fix" by everybody, so we should not do >> it without an explicit agreement by many. > > Agreed, but I vote with Fujii-san for back-patching. No problem with backpatching, just wanted some +1s

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Wed, Sep 7, 2016 at 12:47 AM, Masahiko Sawada wrote: > On Tue, Sep 6, 2016 at 11:08 PM, Simon Riggs wrote: >> On 29 August 2016 at 14:52, Fujii Masao wrote: >>> On Sat, Aug 6, 2016 at 6:36 PM, Petr Jelinek

Re: [HACKERS] autonomous transactions

On 8 Sep. 2016 1:38 pm, "Andres Freund" wrote: > > I kind of dislike this approach for a different reason than already > mentioned in this thread: Namely it's not re-usable for implementing > streaming logical replication of large transaction, i.e. allow to decode > & apply

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 7, 2016 at 2:39 AM, Robert Haas wrote: > On Tue, Sep 6, 2016 at 10:28 PM, Claudio Freire > wrote: >>> The problem with this is that we allocate the entire amount of >>> maintenance_work_mem even when the number of actual dead tuples

Re: [HACKERS] GiST penalty functions [PoC]

>autoconf check for IEEE 754 floats Autoconf man says folowing: >it is safe to assume IEEE-754 in most portable code these days https://www.gnu.org/software/autoconf/manual/autoconf.html#Floating-Point-Portability > A union might be more readable Here is union version of the patch. It's slower

Re: [HACKERS] [PATCH] Alter or rename enum value

On 7 September 2016 at 22:14, Tom Lane wrote: > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > > Here is version 6 of the patch, which just adds RENAME VALUE with no IF > > [NOT] EXISTS, rebased onto current master (particularly the > > transactional

Re: [HACKERS] Optimization for lazy_scan_heap

On Wed, Sep 7, 2016 at 4:11 PM, Simon Riggs wrote: > On 7 September 2016 at 04:13, Masahiko Sawada wrote: > >> Since current HEAD could scan visibility map twice, the execution time >> of Patched is approximately half of HEAD. > > Sounds good. > > To

Re: [HACKERS] WAL consistency check facility

On Wed, Sep 7, 2016 at 7:22 PM, Kuntal Ghosh wrote: > Hello, Could you avoid top-posting please? More reference here: http://www.idallen.com/topposting.html > - If WAL consistency check is enabled for a rmgrID, we always include > the backup image in the WAL record.

Re: [HACKERS] Sample configuration files

On 08/29/2016 03:34 AM, Vik Fearing wrote: > We have sample configuration files for postgresql.conf and > recovery.conf, but we do not have them for contrib modules. This patch > attempts to add them. > > Although the patch puts the sample configuration files in the tree, it > doesn't try to

Re: [HACKERS] GiST penalty functions [PoC]

On 09/08/2016 09:39 AM, Михаил Бахтерев wrote: Excuse me for intervention. It depends. For instance, i run PostgreSQL on the modern MIPS CPU, which does not have sqrt support. But you are right, it is supported in most cases. And if execution speed of this very fuction is of concern, sqrtf(x)

Re: [HACKERS] Supporting SJIS as a database encoding

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro > HORIGUCHI > > $ time psql postgres -c 'select t.a from t, generate_series(0, )' > > /dev/null > > real 0m22.696s > user 0m16.991s > sys 0m0.182s> > > Using binsearch the result

Re: [HACKERS] Is tuplesort_heap_siftup() a misnomer?

On 09/08/2016 03:36 AM, Peter Geoghegan wrote: On Wed, Sep 7, 2016 at 2:42 PM, Tom Lane wrote: The reason it's called siftup is that that's what Knuth calls it. See Algorithm 5.2.3H (Heapsort), pp 146-147 in the first edition of Volume 3; tuplesort_heap_siftup corresponds

Re: [HACKERS] Suggestions for first contribution?

On Wed, Sep 07, 2016 at 05:14:44PM +0300, Aleksander Alekseev wrote: > Here is another idea for a contribution - refactoring. Refactoring is not a good early contribution. Refactoring is more likely to succeed once you internalize community code practices through much study of functional

Re: [HACKERS] Parallel build with MSVC

On Thu, Sep 8, 2016 at 3:54 PM, Christian Ullrich wrote: > Much apologizings for coming in late again, but I just realized it would be > better if the user-controlled flags came after all predefined options the > user might want to override. Right now that is only /verbosity

Re: [HACKERS] Parallel build with MSVC

* Noah Misch wrote: Committed. Much apologizings for coming in late again, but I just realized it would be better if the user-controlled flags came after all predefined options the user might want to override. Right now that is only /verbosity in both build and clean operations. Patch

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

On Mon, Jun 20, 2016 at 9:28 PM, Asif Naeem wrote: > Thank you for useful suggestions. PFA patch, I have tried to cover all the > points mentioned. > >> >> Patch needs rebase, it is failing to apply on latest master. And also there are some pending comment fix from Robert.

Re: [HACKERS] Bug in two-phase transaction recovery

On Wed, Sep 7, 2016 at 10:48 PM, Stas Kelvich wrote: > Some time ago two-phase state file format was changed to have variable size > GID, > but several places that read that files were not updated to use new offsets. > Problem > exists in master and 9.6 and can be

Re: [HACKERS] Supporting SJIS as a database encoding

Hello, At Wed, 07 Sep 2016 16:13:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160907.161304.112519789.horiguchi.kyot...@lab.ntt.co.jp> > > Implementing radix tree code, then redefining the format of mapping table > > > to suppot radix tree,

<    1   2