Re: [HACKERS] Tracking wait event for latches

On Thu, Sep 22, 2016 at 6:49 AM, Thomas Munro wrote: > On Thu, Sep 22, 2016 at 1:23 AM, Robert Haas wrote: >> Moreover, it's pretty confusing that we have this general concept of >> wait events in pg_stat_activity, and then here the specific

Re: [HACKERS] Declarative partitioning - another take

Hi Amit, Following sequence of DDLs gets an error -- -- multi-leveled partitions -- CREATE TABLE prt1_l (a int, b int, c varchar) PARTITION BY RANGE(a); CREATE TABLE prt1_l_p1 PARTITION OF prt1_l FOR VALUES START (0) END (250) PARTITION BY RANGE (b); CREATE TABLE prt1_l_p1_p1 PARTITION OF

Re: [HACKERS] Showing parallel status in \df+

I agree with the argument in this thread, having "Source code" as part of \df+ is bit annoying, specifically when output involve some really big PL language functions. Having is separate does make \df+ output more readable. So I would vote for \df++ rather then adding the source code as part of

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Sep 22, 2016 at 8:51 AM, Jeff Janes wrote: > On Tue, Sep 20, 2016 at 10:27 PM, Amit Kapila > wrote: >> >> On Tue, Sep 20, 2016 at 10:24 PM, Jeff Janes wrote: >> > On Thu, Sep 15, 2016 at 11:42 PM, Amit Kapila

Re: [HACKERS] 9.6 TAP tests and extensions

On 13 September 2016 at 22:02, Tom Lane wrote: > Craig Ringer writes: >> While updating an extension for 9.6 I noticed that while the >> $(prove_check) definition is exposed for use by PGXS in >> Makefile.global, extensions can't actually use the TAP

Re: [HACKERS] Hash Indexes

On Thu, Sep 22, 2016 at 8:03 AM, Andres Freund wrote: > On 2016-09-21 22:23:27 -0400, Tom Lane wrote: >> Andres Freund writes: >> > Sure. But that can be addressed, with a lot less effort than fixing and >> > maintaining the hash indexes, by adding the

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Tue, Sep 20, 2016 at 10:27 PM, Amit Kapila wrote: > On Tue, Sep 20, 2016 at 10:24 PM, Jeff Janes wrote: > > On Thu, Sep 15, 2016 at 11:42 PM, Amit Kapila > > wrote: > >> > >> > >> Okay, Thanks for pointing out the same.

Re: [HACKERS] ICU integration

On 31/08/16 04:46, Peter Eisentraut wrote: > Here is a patch I've been working on to allow the use of ICU for sorting > and other locale things. > Hi, first pass review of the patch (somewhat high level at this point). First, there was some discussion about ICU versioning and collation

Re: [HACKERS] ICU integration

On Thu, Sep 8, 2016 at 12:19:39PM -0400, Peter Eisentraut wrote: > On 9/8/16 11:16 AM, Tom Lane wrote: > > This is a problem, if ICU won't guarantee cross-version compatibility, > > because it destroys the argument that moving to ICU would offer us > > collation behavior stability. > > It would

Re: [HACKERS] Hash Indexes

On 2016-09-21 22:23:27 -0400, Tom Lane wrote: > Andres Freund writes: > > Sure. But that can be addressed, with a lot less effort than fixing and > > maintaining the hash indexes, by adding the ability to do that > > transparently using btree indexes + a recheck internally.

Re: [HACKERS] Hash Indexes

Andres Freund writes: > Sure. But that can be addressed, with a lot less effort than fixing and > maintaining the hash indexes, by adding the ability to do that > transparently using btree indexes + a recheck internally. How that > compares efficiency-wise is unclear as of

Re: [HACKERS] to_date_valid()

On 9/9/16 4:48 AM, Andreas 'ads' Scherbaum wrote: > ValidateDate() will tell you if it's a valid date. But not if the > transformation was correct: > > postgres=# SELECT to_date('2011 12 18', ' MM DD'); >to_date > > 2011-12-08 > (1 row) > > (with the patch from Artur)

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

It seems clear that this patch design is not favored by the community, so I'm setting the patch as rejected in the CF app. I think there is interest in managing system resources better, but I don't know what that would look like. -- Peter Eisentraut http://www.2ndQuadrant.com/

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On 9/9/16 2:57 PM, Peter Eisentraut wrote: > On 6/6/16 9:59 AM, Merlin Moncure wrote: >> Thanks for the review. All your comments look pretty reasonable. I'll >> touch it up and resubmit. > > This is the last email in this thread that the commit fest app shows. I > think we are waiting on an

Re: [HACKERS] Tuplesort merge pre-reading

On Tue, Sep 20, 2016 at 3:34 PM, Claudio Freire wrote: > On Fri, Sep 9, 2016 at 9:51 PM, Claudio Freire wrote: >> On Fri, Sep 9, 2016 at 8:13 AM, Heikki Linnakangas wrote: >>> >>> Claudio, if you could also repeat the tests you

Re: [HACKERS] Hash Indexes

On 2016-09-21 19:49:15 +0300, Oskari Saarenmaa wrote: > 21.09.2016, 15:29, Robert Haas kirjoitti: > > For PostgreSQL, I expect the benefits of improving hash indexes to be > > (1) slightly better raw performance for equality comparisons and (2) > > better concurrency. > > There's a third benefit:

Re: [HACKERS] Hash Indexes

On Wed, Sep 21, 2016 at 12:44 PM, Geoff Winkless wrote: > On 21 September 2016 at 13:29, Robert Haas wrote: > > I'd be curious what benefits people expect to get. > > An edge case I came across the other day was a unique index on a large > string:

Re: [HACKERS] Tracking wait event for latches

On Thu, Sep 22, 2016 at 1:23 AM, Robert Haas wrote: > On Tue, Sep 20, 2016 at 7:13 PM, Thomas Munro > wrote: >> This paragraph seems a bit confused. I suggest something more like >> this: "The server process is waiting for one or more

Re: [HACKERS] Better tracking of free space during SP-GiST index build

On 08/25/2016 03:26 AM, Tomas Vondra wrote: On 08/25/2016 01:45 AM, Tom Lane wrote: Over in the thread about the SP-GiST inet opclass, I threatened to post a patch like this, and here it is. The basic idea is to track more than just the very latest page we've used in each of the page

Re: [HACKERS] Hash Indexes

On 21 September 2016 at 13:29, Robert Haas wrote: > I'd be curious what benefits people expect to get. An edge case I came across the other day was a unique index on a large string: postgresql popped up and told me that I couldn't insert a value into the field because the

Re: [HACKERS] Hash Indexes

On Wed, Sep 21, 2016 at 2:11 PM, Jeff Janes wrote: > We are? I thought we were trying to preserve on-disk compatibility so that > we didn't have to rebuild the indexes. Well, that was my initial idea, but ... > Is the concern that lack of WAL logging has generated some

Re: [HACKERS] Hash Indexes

On Wed, Sep 21, 2016 at 08:29:59AM -0400, Robert Haas wrote: > Of course, if we want to implement clustered indexes, that's going to > require significant changes to the heap format ... or the ability to > support multiple heap storage formats. I'm not opposed to that, but I > think it makes

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Wed, Sep 21, 2016 at 02:05:24PM -0300, Alvaro Herrera wrote: > Another consideration is that the present patch lumps together all > ALTER cases in a single counter. This isn't great, but at the same > time we don't want to bloat the stat files by having hundreds of > counters per database, do

Re: [HACKERS] GiST penalty functions [PoC]

Hi Heikki! > Got a link for a description of the RR*-tree? Would be good to reference it > in the patch comments, too. Well, as for now, the best way to reach the paper is DOI 10.1145/1559845.1559929 http://sci-hub.cc/ Authors in conversations clearly stated that they endorse (not sure in correct

Re: [HACKERS] patch: function xmltable

2016-09-18 11:53 GMT+02:00 Pavel Stehule : > Hi > > new update: > > * doc is moved to better place - xml processing functions > * few more regress tests > * call forgotten check_srf_call_placement > another small update - fix XMLPath parser - support multibytes

Re: [HACKERS] Hash Indexes

On Thu, Sep 15, 2016 at 7:13 AM, Robert Haas wrote: > On Thu, Sep 15, 2016 at 1:41 AM, Amit Kapila > wrote: > > I think it is possible without breaking pg_upgrade, if we match all > > items of a page at once (and save them as local copy), rather

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 18 September 2016 at 09:27, Dave Cramer wrote: > > On 10 August 2016 at 01:53, Pavel Stehule wrote: > >> Hi >> >> 2016-08-03 13:54 GMT+02:00 Alexey Grishchenko : >> >>> On Wed, Aug 3, 2016 at 12:49 PM, Alexey Grishchenko <

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

Peter Eisentraut wrote: > How about having the tag not be a column name but a row entry. So you'd > do something like > > SELECT * FROM pg_stat_sql WHERE tag = 'ALTER VIEW'; > > That way, we don't have to keep updating (and re-debating) this when new > command types or subtypes are added. And

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

On 08/02/2016 01:18 AM, Peter Geoghegan wrote: Tape unification Sort operations have a unique identifier, generated before any workers are launched, using a scheme based on the leader's PID, and a unique temp file number. This makes all on-disk state (temp files managed by

Re: [HACKERS] Hash Indexes

21.09.2016, 15:29, Robert Haas kirjoitti: For PostgreSQL, I expect the benefits of improving hash indexes to be (1) slightly better raw performance for equality comparisons and (2) better concurrency. There's a third benefit: with large columns a hash index is a lot smaller on disk than a

Re: [HACKERS] pg_ctl promote wait

On 8/11/16 9:28 AM, Michael Paquier wrote: > I have looked at them and the changes are looking fine for me. So I > have switched the patch as ready for committer, aka you. > > Just a nit: > + if (wait_seconds > 0) > + { > + sleep(1); > + wait_seconds--; > +

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Wed, Sep 21, 2016 at 11:25:14AM -0400, Peter Eisentraut wrote: > On 9/14/16 4:01 PM, Robert Haas wrote: > > I think it is not a good idea to make the command names used here the > > plural forms of the command tags. Instead of "inserts", "updates", > > "imports", etc. just use "INSERT",

Re: [HACKERS] pageinspect: Hash index support

On Tue, Sep 20, 2016 at 11:14 PM, Michael Paquier wrote: > > + > + The type information will be 'm' for a metadata > page, > + 'v' for an overflow page, > 'b' for a bucket page, > + 'i' for a bitmap page, and > 'u' for an unused page. > + >

Re: [HACKERS] Speedup twophase transactions

> On 21 Sep 2016, at 10:32, Michael Paquier wrote: > > On Tue, Sep 20, 2016 at 11:13 PM, Stas Kelvich > wrote: >> >> Putting that before actual WAL replay is just following historical order of >> events. >> Prepared files are pieces of WAL

Re: [HACKERS] Typo in pgstat.h

On 9/21/16 10:04 AM, Michael Paquier wrote: > While going through pgstat.h I bumped into that: > - * as 4-bytes where first byte repersents the wait event class (type of > + * as 4-bytes where first byte represents the wait event class (type of Fixed. There was actually another one of the same a

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On 9/14/16 4:01 PM, Robert Haas wrote: > I think it is not a good idea to make the command names used here the > plural forms of the command tags. Instead of "inserts", "updates", > "imports", etc. just use "INSERT", "UPDATE", "IMPORT". That's simpler > and less error prone - e.g. you won't end

Re: [HACKERS] [PATCH] get_home_path: use HOME

On 9/20/16 1:44 PM, Rudolf Gavlas wrote: > If you think that using the value of HOME variable as the user's home > directory is bad idea, I won't argue with that, I've already expressed > my opinion. What is the real problem here is using home directory of a > user A as a home directory for user

[HACKERS] wal_segment size vs max_wal_size

There is apparently some misbehavior if max_wal_size is less than 5 * wal_segment_size. For example, if you build with --with-wal-segsize=64, then the recovery test fails unless you set max_wal_size to at least 320MB in PostgresNode.pm. The issue is that pg_basebackup fails with: pg_basebackup:

Re: [HACKERS] increasing the default WAL segment size

On 9/21/16 8:12 AM, Robert Haas wrote: >> Oh, I'm on board with increasing the default size a bit. A different >> > default size isn't a non-default compile time option anymore though, and >> > I don't think 1GB is a reasonable default. > But that's not the question. What Peter said was: "maybe

Re: [HACKERS] Tracking wait event for latches

On Wed, Sep 21, 2016 at 10:23 AM, Michael Paquier wrote: > On Wed, Sep 21, 2016 at 11:18 PM, Robert Haas wrote: >> No, that's not what I want to do. I think we should categorize the >> events administratively by their main purpose, rather than

Re: [HACKERS] Tracking wait event for latches

On Wed, Sep 21, 2016 at 10:02 AM, Michael Paquier wrote: > On Wed, Sep 21, 2016 at 10:23 PM, Robert Haas wrote: >> I have to admit that I like the individual event names quite a bit, >> and I think the detail will be useful to users. But I

Re: [HACKERS] Tracking wait event for latches

On Wed, Sep 21, 2016 at 11:18 PM, Robert Haas wrote: > No, that's not what I want to do. I think we should categorize the > events administratively by their main purpose, rather than > technologically by what we're waiting for. So we'd just have three class IDs instead of

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

On Wed, Sep 21, 2016 at 5:54 AM, Petr Jelinek wrote: >>> Reading again the thread, it seems that my previous post [1] was a bit >>> misunderstood. My position is to not introduce any new behavior >>> changes in 9.6, so we could just make the FIRST NUM grammar equivalent >>>

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On Wed, Sep 21, 2016 at 3:40 AM, Craig Ringer wrote: > The only non-horrible one of those is IMO to just let the caller see > an error if they lose the race. It's a function that's intended for > use when you're dealing with indeterminate transaction state after a > server

[HACKERS] Typo in pgstat.h

Hi all, While going through pgstat.h I bumped into that: - * as 4-bytes where first byte repersents the wait event class (type of + * as 4-bytes where first byte represents the wait event class (type of Regards, -- Michael diff --git a/src/include/pgstat.h b/src/include/pgstat.h index

Re: [HACKERS] Tracking wait event for latches

On Wed, Sep 21, 2016 at 10:23 PM, Robert Haas wrote: > I have to admit that I like the individual event names quite a bit, > and I think the detail will be useful to users. But I wonder if > there's a better way to describe the class of events that we're > talking about

Re: [HACKERS] pageinspect: Hash index support

On 09/21/2016 08:43 AM, Michael Paquier wrote: page_stats / page_items should not be used on the metadata page. As these functions are marked as superuser only it is expected that people provides the correct input, especially since the raw page structure is used as the input. btree functions

Re: [HACKERS] Tracking wait event for latches

On Tue, Sep 20, 2016 at 7:13 PM, Thomas Munro wrote: > This paragraph seems a bit confused. I suggest something more like > this: "The server process is waiting for one or more sockets, a timer > or an interprocess latch. The wait happens in a WaitEventSet, >

Re: [HACKERS] pgbench - compute & show latency consistently

Hello Kuntal, transaction type: builtin: TPC-B (sort of) scaling factor: 10 query mode: simple number of clients: 10 number of threads: 1 number of transactions per client: 1000 number of transactions actually processed: 1/1 tps = 85.184871 (including connections establishing) tps =

Re: [HACKERS] Logical Replication WIP

Some partial notes on 0005-Add-logical-replication-workers.patch: Documentation still says that TRUNCATE is supported. In catalogs.sgml for pg_subscription column subpublications I'd add a note that those are publications that live on the remote server. Otherwise one might think by mistake that

Re: [HACKERS] Fix Error Message for allocate_recordbuf() Failure

On Tue, Sep 20, 2016 at 9:25 PM, Michael Paquier wrote: > On Wed, Sep 21, 2016 at 12:32 AM, Robert Haas wrote: >> For what it's worth, I think it's fine. Good error messages are a useful >> thing. >> >> More generally, I think the whole patch

Re: [HACKERS] pageinspect: Hash index support

Hi, > git apply w/ v4 works here, so you will have to investigate what happens on > your side. > Thanks, It works with v4 patch. > As these functions are marked as superuser only it is expected that people > provides the correct input, especially since the raw page structure is used > as the

Re: [HACKERS] more parallel query documentation

On Tue, Sep 20, 2016 at 11:18 AM, Peter Eisentraut wrote: > On 9/19/16 1:22 PM, Robert Haas wrote: >> On Fri, Sep 16, 2016 at 4:28 PM, Alvaro Herrera >> wrote: >>> I agree it should be added. I suggest that it could even be added to

Re: [HACKERS] pageinspect: Hash index support

On Wed, Sep 21, 2016 at 9:21 PM, Jesper Pedersen wrote: > On 09/21/2016 07:24 AM, Ashutosh Sharma wrote: > git apply w/ v4 works here, so you will have to investigate what happens on > your side. Works here as well. >> I continued reviewing your v4 patch and here are

Re: [HACKERS] Hash Indexes

On Tue, Sep 20, 2016 at 7:55 PM, Bruce Momjian wrote: >> If it turns out that it has little benefit, then we don't really need >> to step up our user education. People can just keep using btree like > > The big problem is people coming from other databases and assuming our >

Re: [HACKERS] pageinspect: Hash index support

On 09/21/2016 02:14 AM, Michael Paquier wrote: Adjusted in v4. Thanks for the new version. Code/doc will need an update once the CHI patch goes in. If you are referring to the WAL support, I guess that this patch or the other patch could just rebase and adjust as needed. It is the main

Re: [HACKERS] pageinspect: Hash index support

Hi, On 09/21/2016 07:24 AM, Ashutosh Sharma wrote: The development branch is @ https://github.com/jesperpedersen/postgres/tree/pageinspect_hash I am working on centOS 7. I am still facing the issue when applying your patch using "git apply" command but if i use 'patch' command it works fine

Re: [HACKERS] increasing the default WAL segment size

On Tue, Sep 20, 2016 at 4:42 PM, Andres Freund wrote: > On 2016-09-20 16:32:46 -0400, Robert Haas wrote: >> > Requiring a non-default compile time or even just cluster creation time >> > option for tuning isn't something worth expanding energy on imo. >> >> I don't agree. The

Re: [HACKERS] pageinspect: Hash index support

Hi, > Which platform are you on ? > > The development branch is @ > https://github.com/jesperpedersen/postgres/tree/pageinspect_hash I am working on centOS 7. I am still facing the issue when applying your patch using "git apply" command but if i use 'patch' command it works fine however i am

Re: [HACKERS] pgbench - compute & show latency consistently

On Wed, Sep 21, 2016 at 4:05 PM, Heikki Linnakangas wrote: > pgbench.sgml actually already had the "latency average = ..." version in its > example. Even before this patch, we printed it with a "=" if one of options > that caused per-transaction timings to be measured, like

Re: [HACKERS] pgbench - compute & show latency consistently

(I just pushed the patch, didn't see your post until after that) On 09/21/2016 01:07 PM, Kuntal Ghosh wrote: On Thus, July 7,2016 at 08:39 PM, Fabien COELHO wrote: Also there is still the bug under -t which displays a 0 latency. Your patch clearly fixed the issue. The

Re: [HACKERS] pgbench - compute & show latency consistently

On 07/13/2016 11:39 AM, Fabien COELHO wrote: number of transactions per client: 1000 -latency average = 15.844 ms +latency average: 15.844 ms tps = 618.764555 (including connections establishing) I think what you have here is that colons separate input parameters and equal signs separate

Re: [HACKERS] pgbench - compute & show latency consistently

On Thus, July 7,2016 at 08:39 PM, Fabien COELHO wrote: > Also there is still the bug under -t which displays a 0 latency. Your patch clearly fixed the issue. > The attached patch still fixes that and make it consistent the other way > around, i.e. by using "=" for latency. I

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

On 21/09/16 09:18, Vik Fearing wrote: > On 09/21/2016 08:30 AM, Michael Paquier wrote: >> On Sat, Sep 17, 2016 at 2:04 AM, Masahiko Sawada >> wrote: >>> Since we already released 9.6RC1, I understand that it's quite hard to >>> change syntax of 9.6. >>> But considering

Re: [HACKERS] Logical Replication WIP

On 21/09/16 05:35, Steve Singer wrote: > On Tue, 20 Sep 2016, Peter Eisentraut wrote: > >> On 9/18/16 4:17 PM, Steve Singer wrote: > >> >> I think if we want to prevent the creation of subscriptions that point >> to self, then we need to create a magic token when the postmaster starts >> and

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/Postgr

On Tue, Sep 20, 2016 at 10:33 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, May 26, 2016 at 7:44 PM, Michael Paquier >> wrote: >>> Yeah, it is definitely better to register it. And I have switched the >>> patch as

Re: [HACKERS] Error running custom plugin: “output plugins have to declare the _PG_output_plugin_init symbol”

The link was very helpful. It's a standard 'Attach to process' approach with Visual Studio and it works just as expected. Thank you Ashutosh! -- View this message in context:

Re: [HACKERS] [PATCH] get_home_path: use HOME

> I work in an environment, where servers are administered by people > with different user names and identical uid (0). Multiple users with same uid is orthodox indeed. Just out of curiosity - what environment is this, if it's not a secret? > The usage of HOME environment variable (if set) is

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 20 September 2016 at 22:46, Robert Haas wrote: > I did some cleanup of 0001 (see attached) and was all set to commit it > when I realized what I think is a problem: holding XidGenLock doesn't > seem to help with the race condition between this function and CLOG >

Re: [HACKERS] Speedup twophase transactions

On Tue, Sep 20, 2016 at 11:13 PM, Stas Kelvich wrote: >> On 20 Sep 2016, at 09:40, Michael Paquier wrote: >> + StartupCLOG(); >> + StartupSUBTRANS(checkPoint.oldestActiveXid); >> + RecoverPreparedFromFiles(); >> [...] >>/* >>

Re: [HACKERS] GiST penalty functions [PoC]

On 09/14/2016 07:57 PM, Andrew Borodin wrote: Here is v6 of cube penalty patch. There was a warning about unused edge function under systems without __STDC_IEC_559__ defined, this patch fixes it. Thanks! Reading through this thread again, I think we got a bit side-tracked with this float

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

On 09/21/2016 08:30 AM, Michael Paquier wrote: > On Sat, Sep 17, 2016 at 2:04 AM, Masahiko Sawada > wrote: >> Since we already released 9.6RC1, I understand that it's quite hard to >> change syntax of 9.6. >> But considering that we support the quorum commit, this could be

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

Hi Rajkumar, On Fri, Sep 16, 2016 at 6:00 PM, Rajkumar Raghuwanshi wrote: > > On Fri, Sep 9, 2016 at 3:17 PM, Ashutosh Bapat > wrote: >> >> Hi All, >> >> PFA the patch to support partition-wise joins for partitioned

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

Hi, I got a server crash with partition_wise_join, steps to reproduce given below. postgres=# set enable_partition_wise_join=true; SET postgres=# CREATE TABLE tbl (a int,c text) PARTITION BY LIST(a); CREATE TABLE postgres=# CREATE TABLE tbl_p1 PARTITION OF tbl FOR VALUES IN (1, 2); CREATE TABLE

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

On Sat, Sep 17, 2016 at 2:04 AM, Masahiko Sawada wrote: > Since we already released 9.6RC1, I understand that it's quite hard to > change syntax of 9.6. > But considering that we support the quorum commit, this could be one > of the solutions in order to avoid breaking

Re: [HACKERS] Supporting SJIS as a database encoding

Hello, At Tue, 13 Sep 2016 11:44:01 +0300, Heikki Linnakangas wrote in <7ff67a45-a53e-4d38-e25d-3a121afea...@iki.fi> > On 09/08/2016 09:35 AM, Kyotaro HORIGUCHI wrote: > > Returning in UTF-8 bloats the result string by about 1.5 times so > > it doesn't seem to make sense

Re: [HACKERS] pageinspect: Hash index support

On Wed, Sep 21, 2016 at 3:25 AM, Jesper Pedersen wrote: > On 09/20/2016 12:45 PM, Jeff Janes wrote: >> Is the 2nd "1" in this call needed? >> >> SELECT * FROM hash_page_stats(get_raw_page('mytab_index', 1), 1) >> >> As far as I can tell, that argument is only used to

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Wed, Sep 21, 2016 at 3:48 AM, Tomas Vondra wrote: > > I have no idea what's causing this - it might be related to the kernel, but > I'm not sure why it should affect the patches differently. Let's see how the > new kernel affects this. > > dilip / sync=off