Re: [HACKERS] Creating unique or "internal-use-only" column names (ColumnRef)

Am 07.09.2015 um 16:40 schrieb Tom Lane: Andrew Dunstan writes: On 09/07/2015 09:28 AM, Alvaro Herrera wrote: This seems pretty much the same as a junk attribute, if I understand you correctly. I suggest given a look at how those work. Is that actually documented

Re: Hooking at standard_join_search (Was: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual)

On 2015/09/04 0:33, Robert Haas wrote: I'm worried that trawling through that SpecialJoinInfo data will end up needing to duplicate much of make_join_rel and add_paths_to_joinrel. For example, consider: SELECT * FROM verysmall v JOIN (bigft1 FULL JOIN bigft2 ON bigft1.x = bigft2.x) ON v.q =

Re: [HACKERS] pgbench progress with timestamp

Use milliseconds for consistency with the '%n' log_prefix patch currently submitted by Tomas Vondra in the CF. sh> ./pgbench -P 1 -N -T 100 -c 2 starting vacuum...end. progress: 1.0 s, 546.0 tps, lat 3.619 ms stddev 4.426 progress: 2.0 s, 575.0 tps, lat 3.480 ms stddev 1.705 sh>

Re: [HACKERS] Horizontal scalability/sharding

On Thu, Sep 3, 2015 at 7:03 AM, Josh Berkus wrote: > On 09/02/2015 11:41 AM, Robert Haas wrote: > > 4. Therefore, I think that we should instead use logical replication, > > which might be either synchronous or asynchronous. When you modify > > one copy of the data, that

Re: [HACKERS] Use pg_rewind when target timeline was switched

On Tue, Sep 8, 2015 at 1:14 AM, Alexander Korotkov wrote: > On Thu, Aug 20, 2015 at 9:57 AM, Michael Paquier wrote: >> The code above looks correct to me when scanning the WAL history onwards >> though, which is what is done when extracting the page map, but not >> backwards when we try to find

[HACKERS] Re: [HACKERS] 答复：[HACKERS] about fsync in CLOG buffer write

On Sun, Sep 6, 2015 at 7:34 AM, 周正中(德歌) wrote: > > >On 2015-09-10 19:39:59 +0800, 张广舟(明虚) wrote: > >> We found there is a fsync call when CLOG buffer > > >> is written out in SlruPhysicalWritePage(). It is often called when a > >> backend > >> needs to check

Re: Hooking at standard_join_search (Was: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual)

On 2015/09/02 23:30, Tom Lane wrote: > Etsuro Fujita writes: >> On 2015/08/01 23:25, Tom Lane wrote: >>> In my vision you probably really only want one call per build_join_rel >>> event (that is, per construction of a new RelOptInfo), not per >>> make_join_rel event.

Re: [HACKERS] [PATCH] Microvacuum for gist.

Something goes wrong... gist.c:1465:5: warning: unused variable 'minoff' [-Wunused-variable] minoff, gistget.c:37:1: warning: unused function 'gistkillitems' [-Wunused-function] gistkillitems(IndexScanDesc scan) Without microvacuum. All 'select' queries are

Re: [HACKERS] [PATCH] Microvacuum for gist.

BTW, I slightly modify your test to provide more stable results. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ drop table test; CREATE TABLE test (box box); alter table test set

Re: [HACKERS] Small patch to fix an O(N^2) problem in foreign keys

Jan Wieck wrote: > The problem is a cache introduced in commit 45ba4247 that improves That's a bit off; 45ba424f seems to be what you mean. > foreign key lookups during bulk updates when the FK value does not > change. When restoring a schema dump from a database with many

Re: [HACKERS] proposal: function parse_ident

On Fri, Sep 4, 2015 at 12:24 AM, Pavel Stehule wrote: > The alghoritm for parsing identifiers is same - the differences are in a > names of levels, and in ending symbols. > > I don't would to write totally generic parser - more without access to > system catalog or

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Tue, Sep 8, 2015 at 6:58 AM, Pavel Stehule wrote: >> >> But you will still lock on the slots list to find an unused one. How is that substantially different from what I'm doing? > > It is not necessary - you can use similar technique to what it does PGPROC. I am

Re: [HACKERS] DBT-3 with SF=20 got failed

> Hello KaiGai-san, > > I've discovered a bug in the proposed patch - when resetting the hash > table after the first batch, it does this: > > memset(hashtable->buckets, 0, sizeof(nbuckets * sizeof(HashJoinTuple))); > > The first 'sizeof' is bogus, so this only zeroes the first 8 bytes of > the

Re: [HACKERS] checkpointer continuous flushing

On Sat, Sep 5, 2015 at 12:26 PM, Fabien COELHO wrote: > > I would be curious whether flushing helps, though. >>> >>> Yes, me too. I think we should try to reach on consensus for exact >>> scenarios and configuration where this patch('es) can give benefit or we >>> want

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On 2015-09-07 22:55:50 +0900, Michael Paquier wrote: > So, to summarize the state of this patch whose status is now "Waiting > on Author", we have the following possibilities: > 1) Keep the test as-is, as an independent test of src/test/modules. I find that a bad option. A test that takes this

Re: [HACKERS] Separating Buffer LWlocks

On 2015-09-08 14:31:53 -0400, Robert Haas wrote: > On Tue, Sep 8, 2015 at 2:19 PM, Andres Freund wrote: > > On 2015-09-08 14:15:32 -0400, Robert Haas wrote: > >> We could do that, but I'm not sure just calling LWLockNewTrancheId() > >> for all of the tranches would be so bad

Re: [HACKERS] Horizontal scalability/sharding

On 2015-09-08 19:52, Robert Haas wrote: On Fri, Sep 4, 2015 at 6:52 PM, Ozgun Erdogan wrote: For Citus, a second part of the question is as FDW writers. We implemented cstore_fdw, json_fdw, and mongo_fdw, and these wrappers don't benefit from even the simple join pushdown

Re: Hooking at standard_join_search (Was: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual)

On Tue, Sep 8, 2015 at 5:35 AM, Etsuro Fujita wrote: > On 2015/09/04 0:33, Robert Haas wrote: >> I'm worried that trawling through that >> SpecialJoinInfo data will end up needing to duplicate much of >> make_join_rel and add_paths_to_joinrel. For example, consider:

Re: [HACKERS] [PATCH v2] GSSAPI encryption support

Michael Paquier writes: > On Fri, Jul 3, 2015 at 3:22 AM, Robbie Harwood wrote: > >> Hello -hackers, >> >> As previously discussed on this list, I have coded up GSSAPI encryption >> support. If it is easier for anyone, this code is also available

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 9/7/15 7:32 PM, Alvaro Herrera wrote: > Andrew Dunstan wrote: > >> I already gave a use case that you dismissed in favour of a vague solution >> that we don't actually have. You seem to be the only person objecting to >> this proposal. > > I think that use case would be better served by a

Re: [HACKERS] pgsql: Improve logging of TAP tests.

* Andrew Dunstan (and...@dunslane.net) wrote: > Improve logging of TAP tests. [...] This broke 'make check' for REL9_4_STABLE with --enable-tap-tests because it added a reference to 'with_temp_install' but didn't actually define it. The attached seems to fix it. Would be great to get feedback

Re: Hooking at standard_join_search (Was: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual)

On Thu, Sep 3, 2015 at 11:51 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Sep 2, 2015 at 1:47 PM, Tom Lane wrote: >>> Offhand I think that the >>> most likely way to build that text will be to examine the query's jointree

[HACKERS] ALTER INDEX...SET tab completion

I can never remember the syntax for setting index storage parameters. Is it =, TO, or just a space between the parameter name and the setting? This makes the tab completion more helpful, by providing the (mandatory) equals sign. Cheers, Jeff alter_index_tabcomplete_v1.patch Description:

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 9/7/15 7:21 PM, Andrew Dunstan wrote: > I already gave a use case that you dismissed in favour of a vague > solution that we don't actually have. But that's also the only use case so far, which seems a little thin. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Horizontal scalability/sharding

On Mon, Sep 7, 2015 at 1:33 PM, Ahsan Hadi wrote: > I > > On Monday, September 7, 2015, Ashutosh Bapat > wrote: >> >> >> >> On Sat, Sep 5, 2015 at 4:22 AM, Ozgun Erdogan wrote: >>> >>> Hey Robert, >>> Now

Re: [HACKERS] DBT-3 with SF=20 got failed

On Tue, Sep 8, 2015 at 8:28 AM, Kouhei Kaigai wrote: >> Hello KaiGai-san, >> >> I've discovered a bug in the proposed patch - when resetting the hash >> table after the first batch, it does this: >> >> memset(hashtable->buckets, 0, sizeof(nbuckets * sizeof(HashJoinTuple)));

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

On Tue, Sep 8, 2015 at 9:29 AM, Kevin Grittner wrote: > I'm not saying we shouldn't have something like this; but we need a > clear definition of that common problem we are solving. I don't > think I've seen that yet. I've seen various spins on solutions > described, from

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > rotate ~ sounds like transpose matrix, what is not true in this case. The various definitions that I can see, such as http://dictionary.reference.com/browse/rotate make no mention of matrices. It applies to anything that moves around a pivot or axis. OTOH, the

Re: [HACKERS] pgsql: Improve logging of TAP tests.

On 09/08/2015 02:58 PM, Stephen Frost wrote: * Andrew Dunstan (and...@dunslane.net) wrote: Improve logging of TAP tests. [...] This broke 'make check' for REL9_4_STABLE with --enable-tap-tests because it added a reference to 'with_temp_install' but didn't actually define it. The attached

Re: [HACKERS] pgsql: Improve logging of TAP tests.

* Andrew Dunstan (and...@dunslane.net) wrote: > On 09/08/2015 02:58 PM, Stephen Frost wrote: > >Would be great to get feedback on it as I'm no Makefile expert (it took > >me far too long to run down what was happening and work out what seemed > >like the right fix..). > > > Seems OK to me from a

Re: [HACKERS] [PATCH] Microvacuum for gist.

Fixed patch is attached. 08.09.2015 13:47, Teodor Sigaev: BTW, I slightly modify your test to provide more stable results. Thank you, I tried it, Results are nearly the same. Without microvacuum Time: 312,955 ms Time: 264,597 ms Time: 243,286 ms Time: 243,679 ms With microvacuum: Time:

Re: [HACKERS] [patch] Proposal for \rotate in psql

2015-09-08 22:55 GMT+02:00 Daniel Verite : > Pavel Stehule wrote: > > > rotate ~ sounds like transpose matrix, what is not true in this case. > for me the relation rotation is exactly what \x does > > The various definitions that I can see, such as >

Re: [HACKERS] missing locking in at least INSERT INTO view WITH CHECK

* Andres Freund (and...@anarazel.de) wrote: > On 2015-08-27 18:37:10 +0100, Dean Rasheed wrote: > > Yes, I concur. It now needs an acquireLocksOnSubLinks_context with > > for_execute = true, but otherwise it should work. > > Ok, I'll push that then, unless somebody else wants to do the honors.

Re: [HACKERS] Allow replication roles to use file access functions

Heikki, * Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 09/04/2015 08:14 AM, Michael Paquier wrote: > >Of course, that's not mandatory to fetch them. It is as well not worth > >the complication to apply a filter to not fetch a portion of the > >files, and I think that's why Heikki took the

Re: [HACKERS] [PATCH] Microvacuum for gist.

On 8 September 2015 at 22:35, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > > Fixed patch is attached. > > 08.09.2015 13:47, Teodor Sigaev: > >> BTW, I slightly modify your test to provide more stable results. >> > > Thank you, I tried it, Results are nearly the same. > > Without

Re: [HACKERS] DBT-3 with SF=20 got failed

On 09/08/2015 08:44 PM, Robert Haas wrote: On Tue, Sep 8, 2015 at 8:28 AM, Kouhei Kaigai wrote: Hello KaiGai-san, I've discovered a bug in the proposed patch - when resetting the hash table after the first batch, it does this: memset(hashtable->buckets, 0,

Re: [HACKERS] Getting total and free disk space from paths in PGDATA

Michael Paquier wrote: > There is currently no in-core function to query the amount of > available and free space in a path of PGDATA, with something like that > for example: > SELECT * FROM pg_get_diskspace_info('pg_xlog'); > total_space | free_space >

Re: [HACKERS] proposal: function parse_ident

2015-09-08 20:17 GMT+02:00 Corey Huinker : > > > I would have immediate use for this. So often a function is written with a > table name as a parameter and it's not immediately clear if the schema is > to be parsed out of the string, prescribed, or a separate

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 09/08/2015 04:21 PM, Peter Eisentraut wrote: On 9/7/15 7:32 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: I already gave a use case that you dismissed in favour of a vague solution that we don't actually have. You seem to be the only person objecting to this proposal. I think that use

Re: [HACKERS] New functions

On Tue, Sep 8, 2015 at 9:32 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > I made a couple extra cleanups to the patch, namely: do not call > CreateTemplateTupleDesc() just to discard the resulting tupdesc with a > subsequent get_call_result_type(); and do not write a \0 to the > BIO_s_mem,

[HACKERS] patch for geqo tweaks

I have two patches to make the geqo initialization and mutation slightly better. The first adjusts the mutation swaps to avoid having to re-pick ties. The second changes the initialization and shuffling algorithm for the gene array to use an in-place Fisher-Yates shuffling algorithm. Diffs

[HACKERS] 答复：[HACKERS] 答复：[HACKERS] about fsync in CLOG buffer write

HI,  this is the test case:Use stap track pg_clog/* fsync call. [root@digoal ~]# cat trc.stp  global f_start[99] probe  process("/opt/pgsql/bin/postgres").function("SlruPhysicalWritePage@/opt/soft_bak/postgresql-9.4.4/src/backend/access/transam/slru.c").call  {     f_start[execname(), pid(), 

Re: [HACKERS] New functions

Michael Paquier wrote: > On Tue, Sep 8, 2015 at 9:32 AM, Alvaro Herrera wrote: > > Michael Paquier wrote: > > I made a couple extra cleanups to the patch, namely: do not call > > CreateTemplateTupleDesc() just to discard the resulting tupdesc with a > > subsequent get_call_result_type(); and do

[HACKERS] Memory Context Info dump

In our customer environment as well as during development, we have observed that many time we need to get details of memory used by each contexts in order to analyze the memory consumption/leak. So I would like to propose one contrib function interface, which will dump the whole memory context

Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

On 09/05/2015 02:47 AM, Oskari Saarenmaa wrote: There was a long thread about concatenating jsonb objects to each other, but that discussion didn't touch concatenating other types. Currently jsonb_concat always just returns the other argument if one of arguments is considered empty. This

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

Bruce Momjian wrote: > It is annoying for less capable database to say they have high > availability when that just involves having a client library that > can connect to multiple hosts. This sounds like the "But all the *other* kids are doing it!" argument, which comes up

Re: [HACKERS] Counting lines correctly in psql help displays

On 9/5/15 3:50 PM, Tom Lane wrote: Greg Stark writes: But that said, here's a tricksy patch that triggers an assertion failure if the expected_lines is wrong. I intended it to trigger in the regression tests so it only checks if the pager is actually off. It wouldn't be hard to

Re: [HACKERS] Counting lines correctly in psql help displays

Jim Nasby writes: > On 9/5/15 3:50 PM, Tom Lane wrote: >> Greg Stark writes: >>> But that said, here's a tricksy patch that triggers an assertion >>> failure if the expected_lines is wrong. >> Hmm ... that would put a premium on the linecount always

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 9/6/15 7:25 AM, Andres Freund wrote: On 2015-08-10 07:03:02 +0100, Simon Riggs wrote: I was previously a proponent of (2) as a practical way forwards, but my proposal here today is that we don't do anything further on 2) yet, and seek to make progress on 5) instead. If 5) fails to bring a

Re: [HACKERS] Making tab-complete.c easier to maintain

On Tue, Sep 8, 2015 at 1:56 AM, Alvaro Herrera wrote: > Thomas Munro wrote: > > > Thanks, good point. Here's a version that uses NULL via a macro ANY. > > Aside from a few corrections it also now distinguishes between > > TAIL_MATCHESn (common) and MATCHESn (rarely

Re: [HACKERS] checkpointer continuous flushing

Hello Amit, I have done some tests with both the patches(sort+flush) and below are results: Thanks a lot for these runs on this great harware! Test - 1 (Data Fits in shared_buffers) Rounded for easier comparison: flush/sort off off: 27480.4 ± 12791.1 [ 0, 16009, 32109, 37629,

Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

On 09/08/2015 10:48 AM, Teodor Sigaev wrote: This looks correct. Barring objection I'll apply this shortly. +1 Seems correct. Should we backpatch that? Yes, certainly. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] patch for geqo tweaks

On 8 September 2015 at 14:44, Nathan Wagner wrote: > I have two patches to make the geqo initialization and mutation > slightly better. > > The first adjusts the mutation swaps to avoid having to re-pick > ties. The second changes the initialization and shuffling

Re: [HACKERS] Allow a per-tablespace effective_io_concurrency setting

Julien Rouhaud wrote: > Hi, > > Please find attached a v2 of the patch. See below for changes. Pushed after smallish tweaks. Please test to verify I didn't break anything. (It's a pity that we can't add a regression test with a value other than 0.) -- Álvaro Herrera

Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

This looks correct. Barring objection I'll apply this shortly. +1 Seems correct. Should we backpatch that? -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers

Re: [HACKERS] pgbench progress with timestamp

On Mon, Sep 7, 2015 at 11:25 PM, Fabien COELHO wrote: > > Use milliseconds for consistency with the '%n' log_prefix patch currently >>> submitted by Tomas Vondra in the CF. >>> >>> sh> ./pgbench -P 1 -N -T 100 -c 2 >>> starting vacuum...end. >>> progress: 1.0 s, 546.0

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On Wed, Sep 2, 2015 at 02:30:33PM -0300, Alvaro Herrera wrote: > > I think we should rather add *one* test that does dump/restore over the > > normal regression test database. Something similar to the pg_upgrade > > tests. And then work at adding more content to the regression test > > database -

Re: [HACKERS] snapshot too old, configured by time

On 08/31/2015 10:07 AM, Kevin Grittner wrote: Kevin, I've started to do a review on this patch but I am a bit confused with some of what I am seeing. The attached testcase fails I replace the cursor in your test case with direct selects from the table. I would have expected this to

Re: [HACKERS] pgsql: Improve logging of TAP tests.

On Tue, Sep 08, 2015 at 02:58:36PM -0400, Stephen Frost wrote: > * Andrew Dunstan (and...@dunslane.net) wrote: > > Improve logging of TAP tests. > > [...] > > This broke 'make check' for REL9_4_STABLE with --enable-tap-tests > because it added a reference to 'with_temp_install' but didn't

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On Wed, Sep 9, 2015 at 3:33 AM, Andres Freund wrote: > On 2015-09-07 22:55:50 +0900, Michael Paquier wrote: >> So, to summarize the state of this patch whose status is now "Waiting >> on Author", we have the following possibilities: >> 1) Keep the test as-is, as an independent

Re: [HACKERS] Getting total and free disk space from paths in PGDATA

On Wed, Sep 9, 2015 at 6:13 AM, Kevin Grittner wrote: > Michael Paquier wrote: > When I was working with Wisconsin Courts we needed something like > this, and wrote it. It has been used on hundreds of clusters, > 24/7, for years. I see that the last publicly posted updated was > in 2008, but it

Re: [HACKERS] checkpointer continuous flushing

On Tue, Sep 8, 2015 at 8:09 PM, Fabien COELHO wrote: > > > Thanks a lot, again, for these tests! > > I think that we may conclude, on these run: > > (1) sorting seems not to harm performance, and may help a lot. > I agree with first part, but about helping a lot, I am not

Re: [HACKERS] Getting total and free disk space from paths in PGDATA

On Mon, Sep 7, 2015 at 11:47 AM, Tom Lane wrote: > Michael Paquier writes: >> statvfs is part of the POSIX spec and is "normally" present on modern >> platforms (BSD, OSX, Linux and Solaris have it as far as I saw, still >> there may be some strange

Re: [HACKERS] proposal: function parse_ident

Hi I sending the path with little bit enhanced parser - it doesn't support utf8 alpha in identifiers yet Regards Pavel diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml new file mode 100644 index b3b78d2..75ea33a *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgml

Re: [HACKERS] Memory Context Info dump

On Tue, Sep 8, 2015 at 4:30 PM, Tom Lane wrote: > As an example of potentially-more-useful aids, I'm wondering about > tracking the high-water memory consumption of each memory context. > (This probably wouldn't be terribly expensive if it were done at the > granularity of

Re: [HACKERS] psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx

On 2015-09-08 07:06:04 +0200, Pavel Stehule wrote: > 2015-09-07 21:44 GMT+02:00 Andres Freund : > > The spellings for boolean values were a relatively small subset of what > > the backend accepts - it's now on,off,true,false,yes,no,1,0. I'm not > > sure whether that's a good

[HACKERS] Odd/undocumented precedence of concatenation operator

Hi hackers. Trying to execute the following query on PostgreSQL 9.4.4: select 'a' >= 'b' || 'c'; Gives the result "falsec", implying that the precedence of the string concatenation operator is lower than the comparison operator. Changing the >= into = provides the result false, which is less

Re: [HACKERS] gin_fuzzy_search_limit and postgresql.conf.sample

On Fri, Sep 4, 2015 at 4:48 AM, Fujii Masao wrote: > My client found that gin_fuzzy_search_limit is not included in > postgresql.conf.sample. Is this intentional? Or oversight? I assume it's an oversight. It was originally added in

Re: [HACKERS] psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx

Andres Freund wrote: > On 2015-09-08 07:06:04 +0200, Pavel Stehule wrote: > > 2015-09-07 21:44 GMT+02:00 Andres Freund : > > > The spellings for boolean values were a relatively small subset of what > > > the backend accepts - it's now on,off,true,false,yes,no,1,0. I'm not > >

Re: [HACKERS] Memory Context Info dump

Rajeev rastogi writes: > In our customer environment as well as during development, we have observed > that many time we need to get details of memory used by each contexts in > order to analyze the memory consumption/leak. > So I would like to propose one contrib

Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

On 8 September 2015 at 15:48, Teodor Sigaev wrote: > This looks correct. Barring objection I'll apply this shortly. >> > > +1 Seems correct. Should we backpatch that? > Yes, this needs correcting in 9.5 where it has been introduced. Thom

Re: [HACKERS] proposal: function parse_ident

2015-09-08 14:06 GMT+02:00 Robert Haas : > On Fri, Sep 4, 2015 at 12:24 AM, Pavel Stehule > wrote: > > The alghoritm for parsing identifiers is same - the differences are in a > > names of levels, and in ending symbols. > > > > I don't would to

Re: [HACKERS] Separating Buffer LWlocks

On Mon, Sep 7, 2015 at 1:59 PM, Andres Freund wrote: > On 2015-09-06 15:28:40 +0200, Andres Freund wrote: >> Hm. I found that the buffer content lwlocks can actually also be a >> significant source of contention - I'm not sure reducing padding for >> those is going to be

Re: [HACKERS] gin_fuzzy_search_limit and postgresql.conf.sample

On Wed, Sep 9, 2015 at 2:00 AM, Teodor Sigaev wrote: >> I assume it's an oversight. It was originally added in > > Agree, it seems so So fixed. Thanks! Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] WIP: Access method extendability

On Mon, Sep 7, 2015 at 3:32 PM, Teodor Sigaev wrote: > Petr Jelinek wrote: >> >> On 2015-09-07 17:41, Teodor Sigaev wrote: >>> >>> Some notices: >>> >>> 1) create-am.3.patch.gz >>>As I understand, you didn't add schema name to access method. Why? >>> Suppose, if we implement

Re: [HACKERS] [patch] Proposal for \rotate in psql

On Mon, Sep 7, 2015 at 5:08 PM, David G. Johnston wrote: > Given the role that psql performs I do think \rotate to be the least > problematic choice; I concur that avoiding \pivot is desirable due to SQL's > usage. I can't agree. Rotating a matrix has a well-defined

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Sun, Sep 6, 2015 at 3:34 PM, Joe Conway wrote: > On 09/02/2015 02:54 PM, Alvaro Herrera wrote: >> Josh Berkus wrote: >>> On 09/02/2015 02:34 PM, Alvaro Herrera wrote: I think trying to duplicate the exact strings isn't too nice an interface. >>> >>> Well, for

Re: [HACKERS] Horizontal scalability/sharding

On Fri, Sep 4, 2015 at 6:52 PM, Ozgun Erdogan wrote: > Distributed shuffles (Map/Reduce) are hard. When we looked at using FDWs for > pg_shard, we thought that Map/Reduce would require a comprehensive revamp of > the APIs. Well, so you've said. But what kind of API do you

Re: [HACKERS] Separating Buffer LWlocks

On 2015-09-08 13:29:28 -0400, Robert Haas wrote: > I like this approach, though I think clearly it needs more performance > testing. Yea, obviously. I did run this on a slightly bigger machine yesterday and it gave consistent ~8% performance improvements. > The method of determining the tranche

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Tue, Sep 8, 2015 at 11:49 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > > >> The real problem could be if the process that was signaled to connect > to the message queue never handles the interrupt, and we keep waiting > forever in shm_mq_receive(). We could add a timeout

Re: [HACKERS] gin_fuzzy_search_limit and postgresql.conf.sample

I assume it's an oversight. It was originally added in Agree, it seems so 8a3631f8d86cdd9b07c577d6e213b1fc824db255, the commit that originally added GIN. Documentation was added later that year in 0ca9907ce443c58532f1c09e716b7d9cad9039a5. Why would we intentionally document it but leave it

Re: [HACKERS] Waits monitoring

On Mon, Sep 7, 2015 at 7:33 AM, Ildus Kurbangaliev wrote: >> > Ildus, could you please review Amit & Robert's patch? >> [1] - >> http://www.postgresql.org/message-id/caa4ek1kdec1tm5ya9gkv85vtn4qqsrxzkjru-tu70g_tl1x...@mail.gmail.com > About [1] and [2]. They are

Re: [HACKERS] Freeze avoidance of very large table.

On Mon, Sep 7, 2015 at 11:18 AM, Masahiko Sawada wrote: > On Sat, Sep 5, 2015 at 7:35 AM, Simon Riggs wrote: >> On 3 September 2015 at 18:23, Masahiko Sawada wrote: >>> The previous patch lacks some files for regression test.

Re: [HACKERS] [patch] Proposal for \rotate in psql

On Tue, Sep 8, 2015 at 1:38 PM, Robert Haas wrote: > On Mon, Sep 7, 2015 at 5:08 PM, David G. Johnston > wrote: > > Given the role that psql performs I do think \rotate to be the least > > problematic choice; I concur that avoiding \pivot is

Re: [HACKERS] [patch] Proposal for \rotate in psql

On Tue, Sep 8, 2015 at 2:10 PM, David G. Johnston wrote: > On Tue, Sep 8, 2015 at 1:38 PM, Robert Haas wrote: >> On Mon, Sep 7, 2015 at 5:08 PM, David G. Johnston >> wrote: >> > Given the role that psql performs I do

Re: [HACKERS] Separating Buffer LWlocks

On Tue, Sep 8, 2015 at 1:54 PM, Andres Freund wrote: > On 2015-09-08 13:29:28 -0400, Robert Haas wrote: >> I like this approach, though I think clearly it needs more performance >> testing. > > Yea, obviously. I did run this on a slightly bigger machine yesterday > and it

Re: [HACKERS] proposal: function parse_ident

On Tue, Sep 8, 2015 at 8:57 AM, Pavel Stehule wrote: > > > 2015-09-08 14:06 GMT+02:00 Robert Haas : > >> On Fri, Sep 4, 2015 at 12:24 AM, Pavel Stehule >> wrote: >> > The alghoritm for parsing identifiers is same - the

Re: [HACKERS] Separating Buffer LWlocks

On 2015-09-08 14:15:32 -0400, Robert Haas wrote: > We could do that, but I'm not sure just calling LWLockNewTrancheId() > for all of the tranches would be so bad either. To me that seems either fragile or annoying to use. If all backends call LWLockNewTrancheId() we need to a be sure the

Re: [HACKERS] Odd/undocumented precedence of concatenation operator

Shay Rojansky writes: > Trying to execute the following query on PostgreSQL 9.4.4: > select 'a' >= 'b' || 'c'; > Gives the result "falsec", implying that the precedence of the string > concatenation operator is lower than the comparison operator. Changing the > >= into = provides

Re: [HACKERS] Autonomous Transaction is back

On Sun, Sep 6, 2015 at 12:56 AM, Noah Misch wrote: > My comments have flowed out of a principle that autonomous transactions shall > have precisely the same semantics as using another backend via dblink. That's what I thought, too. AT is syntax sugar for dblink approach.

Re: [HACKERS] Allow a per-tablespace effective_io_concurrency setting

On 08/09/2015 18:00, Alvaro Herrera wrote: > Julien Rouhaud wrote: >> Hi, >> >> Please find attached a v2 of the patch. See below for changes. > > Pushed after smallish tweaks. Please test to verify I didn't break > anything. > I just tried with all the cases I could think of, everything works

Re: [HACKERS] 答复：[HACKERS] 答复：[HACKERS] about fsync in CLOG buffer write

Hi, On 2015-09-08 15:58:26 +0800, 周正中(德歌) wrote: > postgres@digoal-> cat 7.sql > select txid_current(); > > postgres@digoal-> pgbench -M prepared -n -r -P 1 -f ./7.sql -c 1 -j 1 -T  > 10 > About 32K tps. > progress: 240.0 s, 31164.4 tps, lat 0.031 ms stddev 0.183 > progress: 241.0 s, 33243.3 

Re: [HACKERS] Use pg_rewind when target timeline was switched

On Tue, Sep 8, 2015 at 10:28 AM, Michael Paquier wrote: > On Tue, Sep 8, 2015 at 1:14 AM, Alexander Korotkov wrote: > > On Thu, Aug 20, 2015 at 9:57 AM, Michael Paquier wrote: > >> The code above looks correct to me when scanning the WAL history onwards > >> though,

Re: [HACKERS] Separating Buffer LWlocks

On Tue, Sep 8, 2015 at 2:19 PM, Andres Freund wrote: > On 2015-09-08 14:15:32 -0400, Robert Haas wrote: >> We could do that, but I'm not sure just calling LWLockNewTrancheId() >> for all of the tranches would be so bad either. > > To me that seems either fragile or annoying to

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

On Mon, Sep 7, 2015 at 9:34 AM, Alvaro Herrera wrote: > Andres Freund wrote: >> The buffer replacement algorithm for clog is rather stupid - I do wonder >> where the cutoff is that it hurts. >> >> Could you perhaps try to create a testcase where xids are accessed that >>

Re: [HACKERS] Counting lines correctly in psql help displays

On 09/05/2015 12:55 PM, Tom Lane wrote: I wrote: BTW, I noticed that the PageOutput line counts for psql's usage(), slashUsage(), and helpVariables() were all three wrong, which I'm afraid has been their usual state in the past too. Since commit 07c8651dd91d5aea there's been a pretty easy