Re: ALTER TABLE ADD COLUMN fast default

On Tue, Feb 20, 2018 at 5:03 PM, Andrew Dunstan wrote: > http://www.publix.com/myaccount/verify?validationCode=889fd4cb-6dbb-4f93-9d4f-c701410cd8a2 Wow, my c was working overtime. Good thing this won't do anyone any good. cheers andrew -- Andrew Dunstan

Re: [WIP PATCH] Index scan offset optimisation using visibility map

Hi! I've played with patch. I observe that in some expected scenarios it reduces read buffers significantly. > 14 февр. 2018 г., в 0:04, Michail Nikolaev > написал(а): > Patch updated + rebased on master. check-world is passing. Minor spots: There are some

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-02-17 00:23:40 +0100, Tomas Vondra wrote: > Anyway, I consider the performance to be OK. But perhaps Andres could > comment on this too, as he requested the benchmarks. My performance concerns were less about CREATE TABLE related things than about analytics workloads or such, where

Re: ALTER TABLE ADD COLUMN fast default

http://www.publix.com/myaccount/verify?validationCode=889fd4cb-6dbb-4f93-9d4f-c701410cd8a2 On Mon, Feb 19, 2018 at 1:18 PM, David Rowley wrote: > On 19 February 2018 at 13:48, Andrew Dunstan > wrote: >> On Sun, Feb 18, 2018 at 2:52

RE: [doc fix] Correct calculation of vm.nr_hugepages

From: Justin Pryzby [mailto:pry...@telsasoft.com] > One can do with fewer greps: > pryzbyj@pryzbyj:~$ sudo pmap `pgrep -P 1 -u postgres` |awk > '/rw-s/&&/zero/{print $2}' # check PPID=1 144848K Thanks, I'd like to take this. Regards Takayuki Tsunakawa hugepage_size_doc_v2.patch Description:

Re: Changing default value of wal_sync_method to open_datasync on Linux

On 2018-02-20 01:56:17 +, Tsunakawa, Takayuki wrote: > Disabling the filesystem barrier is a valid tuning method as the PG manual > says: I don't think it says that: > https://www.postgresql.org/docs/devel/static/wal-reliability.html > > [Excerpt] > Recent SATA drives (those following

Re: SHA-2 functions

On Mon, Feb 19, 2018 at 08:43:44AM -0500, Peter Eisentraut wrote: > I also noticed while working on some SSL code that we have perfectly > good SHA-2 functionality in the server already, but it has no test > coverage outside the SCRAM tests. Yep, the refactoring in src/common/ has been done for

Re: Server crash in pg_replication_slot_advance function

Petr Jelinek wrote: > > Attached patch proposes a required fix. > > > > Looks correct to me. Masahiko Sawada wrote: > The change looks good to me. Thank you. Thanks, pushed. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Typo in procarray.c

Hi, Attached patch for fixing $subject. s/replicaton/replication/ Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center fix_typo_in_procarray_c.patch Description: Binary data

RE: Changing default value of wal_sync_method to open_datasync on Linux

From: Andres Freund [mailto:and...@anarazel.de] > Indeed. My past experience with open_datasync on linux shows it to be slower > by roughly an order of magnitude. Even if that would turn out not to be > the case anymore, I'm *extremely* hesitant to make such a change. Thanks for giving so quick

Re: Changing default value of wal_sync_method to open_datasync on Linux

On 20/02/18 13:27, Tsunakawa, Takayuki wrote: Hello, I propose changing the default value of wal_sync_method from fdatasync to open_datasync on Linux. The patch is attached. I'm feeling this may be controversial, so I'd like to hear your opinions. The reason for change is better

Re: master check fails on Windows Server 2008

Marina Polyakova writes: > On 16-02-2018 19:31, Tom Lane wrote: >> Weird. AFAICS the cost estimates for those two plans should be quite >> different, so this isn't just a matter of the estimates maybe being >> a bit platform-dependent. (And that test has been there

Re: Changing default value of wal_sync_method to open_datasync on Linux

Hi, On 2018-02-20 00:27:47 +, Tsunakawa, Takayuki wrote: > I propose changing the default value of wal_sync_method from fdatasync > to open_datasync on Linux. The patch is attached. I'm feeling this > may be controversial, so I'd like to hear your opinions. Indeed. My past experience with

Changing default value of wal_sync_method to open_datasync on Linux

Hello, I propose changing the default value of wal_sync_method from fdatasync to open_datasync on Linux. The patch is attached. I'm feeling this may be controversial, so I'd like to hear your opinions. The reason for change is better performance. Robert Haas said open_datasync was much

Re: SHA-2 functions

On Mon, Feb 19, 2018 at 03:02:02PM -0500, Peter Eisentraut wrote: > On 2/19/18 09:06, Aleksander Alekseev wrote: >>> So I suggest these patches that expose the new functions sha224(), >>> sha256(), sha384(), sha512(). That allows us to make the SSL and SCRAM >>> tests more robust, and it will

Re: [PROPOSAL] Nepali Snowball dictionary

On Tue, Feb 20, 2018 at 12:01 AM, Arthur Zakirov wrote: > Thank you for your answer! > > 2018-02-19 18:43 GMT+03:00 Tom Lane : >> We are not the upstream for the snowball stuff, and lack the expertise >> to decide whether proposed changes are any

Re: pgsql: Allow UNIQUE indexes on partitioned tables

I found the following change to be confusing. /doc/src/sgml/ref/alter_table.sgml + +Additional restrictions apply when unique indexes are applied to +partitioned tables; see . + That paragraph appears in the section covering "ALTER TABLE name ADD

Re: [PROPOSAL] Nepali Snowball dictionary

Thank you for your answer! 2018-02-19 18:43 GMT+03:00 Tom Lane : > We are not the upstream for the snowball stuff, and lack the expertise > to decide whether proposed changes are any good. To get anything > changed there, you'd have to get it approved by the snowball group. >

Re: unique indexes on partitioned tables

I pushed this now, with fixes for the last few comments there were. Peter Eisentraut wrote: > I don't understand the variable name "third". I don't see a "first" or > "second" nearby. Hah. That was referring to variables "myself" and "referenced". I changed the variable name to

Re: SHA-2 functions

On 2/19/18 09:06, Aleksander Alekseev wrote: >> So I suggest these patches that expose the new functions sha224(), >> sha256(), sha384(), sha512(). That allows us to make the SSL and SCRAM >> tests more robust, and it will allow them to be used in general purpose >> contexts over md5(). > > Nice

Re: JIT compiling with LLVM v10.1

Hi, On 02/14/2018 01:17 PM, Andres Freund wrote: On 2018-02-07 06:54:05 -0800, Andres Freund wrote: I've pushed v10.0. The big (and pretty painful to make) change is that now all the LLVM specific code lives in src/backend/jit/llvm, which is built as a shared library which is loaded on demand.

Re: unique indexes on partitioned tables

Jaime Casanova wrote: > Hi Álvaro, > > attached a tiny patch (on top of yours) that silence two "variables > uninitilized" warnings. Thanks! Applied. > also noted that if you: > > """ > create table t1(i int) partition by hash (i); > create table t1_0 partition of t1 for values with (modulus

Re: unique indexes on partitioned tables

On 12 February 2018 at 15:26, Alvaro Herrera wrote: > Hello, > > Thanks, Peter, Jesper, Amit, for reviewing the patch. Replying to > all review comments at once: > [... v5 of patch attached ...] Hi Álvaro, attached a tiny patch (on top of yours) that silence two

Re: pgbench - allow to specify scale as a size

Hello Mark, What if we consider using ascii (utf8?) text file sizes as a reference point, something independent from the database? Why not. TPC-B basically specifies that rows (accounts, tellers, branches) are all padded to 100 bytes, thus we could consider (i.e. document) that

Re: extern keyword incorrectly used in some function definitions

David Rowley writes: > While poking around partition.c I noticed that one of the functions > there is *defined* as "extern". Normally we'd only do this in the > declaration of the function. I don't really see why it's needed in the > definition. > Anyway, I removed

Re: pgbench - allow to specify scale as a size

On Sat, Feb 17, 2018 at 12:22:37PM -0500, Alvaro Hernandez wrote: > > > On 17/02/18 12:17, Tom Lane wrote: > > Alvaro Hernandez writes: > >> On 17/02/18 11:26, Tom Lane wrote: > >>> Fabien COELHO writes: > Here is a attempt at extending --scale so

Re: autovacuum: change priority of the vacuumed tables

On 02/19/2018 03:38 PM, Ildus Kurbangaliev wrote: > On Fri, 16 Feb 2018 21:48:14 +0900 > Masahiko Sawada wrote: > >> On Fri, Feb 16, 2018 at 7:50 PM, Ildus Kurbangaliev >> wrote: >>> On Fri, 16 Feb 2018 17:42:34 +0900 >>> Masahiko Sawada

Re: NEXT VALUE FOR sequence

Laurenz Albe writes: > The SQL standard has the expression "NEXT VALUE FOR asequence" to do > what we traditionally do with "nextval('asequence')". > This is an attempt to implement this on top of the recently introduced > NextValueExpr node. This has been proposed

Re: autovacuum: change priority of the vacuumed tables

On Fri, 16 Feb 2018 21:48:14 +0900 Masahiko Sawada wrote: > On Fri, Feb 16, 2018 at 7:50 PM, Ildus Kurbangaliev > wrote: > > On Fri, 16 Feb 2018 17:42:34 +0900 > > Masahiko Sawada wrote: > > > >> On Thu, Feb 15,

Re: CURRENT OF causes an error when IndexOnlyScan is used

01.02.2018 05:12, Tom Lane: Yugo Nagata writes: I'm sorry the patch attached in the previous mail is broken and not raises a compile error. I attached the fixed patch. This patch is almost certainly wrong: you can't assume that the scan-level state matches the tuple we

Re: SHA-2 functions

On 02/19/2018 08:43 AM, Peter Eisentraut wrote: > I also noticed while working on some SSL code that we have perfectly > good SHA-2 functionality in the server already, but it has no test > coverage outside the SCRAM tests. > > So I suggest these patches that expose the new functions sha224(), >

[PROPOSAL] Nepali Snowball dictionary

Hello hackers, I would like to propose nepali snowball dictionary patch. Nepali is inflectional and derivational language. And it can be stemmed. initdb also patched, so it can determine default text search configuration. Examples: =# select ts_lexize('nepali_stem', 'लेख्'); ts_lexize

Re: SHA-2 functions

Hello Peter, > So I suggest these patches that expose the new functions sha224(), > sha256(), sha384(), sha512(). That allows us to make the SSL and SCRAM > tests more robust, and it will allow them to be used in general purpose > contexts over md5(). Nice patch. I wonder though whether tests

SHA-2 functions

There was a complaint recently about the documentation using the widely frowned-upon md5() function in an unrelated context as an example hash function. This is quite common in many examples, such as hashing row values to compare them, or hashing datums if they don't fit into an index. But there

Re: [HACKERS] path toward faster partition pruning

On 19 February 2018 at 22:19, Amit Langote wrote: > Attached updated patches. Thanks again! Thanks for making those changes. I've made another pass of v28 and have a few more comments. The patch is starting to look good, but there are some new changes in recent

Re: NEXT VALUE FOR sequence

Laurenz Albe wrote: > The SQL standard has the expression "NEXT VALUE FOR asequence" to do > what we traditionally do with "nextval('asequence')". The behavior mandated by the standard is that several invocations of NEXT VALUE on the same sequence on the same output row must produce the

Tracking object modification time using event triggers

Hi all. I'm lead developer for pgCodeKeeper which is a tool for PostgreSQL database schema comparison. In our tool we have a pg_dump-like schema reader for comparing against live DB instances. This reader consumes majority of the time the comparison operation takes and we had an idea to speed it

Re: [doc fix] Correct calculation of vm.nr_hugepages

On Mon, Feb 19, 2018 at 07:05:47AM +, Tsunakawa, Takayuki wrote: > The current PostgreSQL documentation overestimates the number of huge pages > (vm.nr_hugepages) because the calculation uses the maximum virtual address > space. In practice, huge pages are only used for the anonymous shared

Re: Prefix operator for text and spgist support

Hello, On Fri, Feb 02, 2018 at 06:03:27PM +0300, Ildus Kurbangaliev wrote: > Hi, > > Attached patch introduces prefix operator ^@ for text type. For 'a ^@ b' > it returns true if 'a' starts with 'b'. Also there is spgist index > support for this operator. > > It could be useful as an

NEXT VALUE FOR sequence

The SQL standard has the expression "NEXT VALUE FOR asequence" to do what we traditionally do with "nextval('asequence')". This is an attempt to implement this on top of the recently introduced NextValueExpr node. If there is no obvious reason why we would not want that, I'll add it to the next

extern keyword incorrectly used in some function definitions

While poking around partition.c I noticed that one of the functions there is *defined* as "extern". Normally we'd only do this in the declaration of the function. I don't really see why it's needed in the definition. Anyway, I removed it. I then thought I'd better look around for any others

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 19 February 2018 at 18:01, David Rowley wrote: > On 19 February 2018 at 15:11, Tomas Vondra > wrote: >> and perhaps we should do s/isproxy/is_proxy/ which seems like the usual >> naming for boolean variables. > > You're right. I'll