[HACKERS] Precedence of new phrase search tsquery operator

It appears that the new <-> operator has been made to have exactly the same grammatical precedence as the existing & (AND) operator. Thus, for example, 'a & b <-> c'::tsquery means something different from 'b <-> c & a'::tsquery: regression=# select 'a & b <-> c'::tsquery; tsquery

Re: [HACKERS] Precedence of new phrase search tsquery operator

On Wed, Jun 8, 2016 at 7:13 PM, Tom Lane wrote: > It appears that the new <-> operator has been made to have exactly the > same grammatical precedence as the existing & (AND) operator. Thus, > for example, 'a & b <-> c'::tsquery means something different from > 'b <-> c &

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 8, 2016 at 6:31 PM, Robert Haas wrote: > > On Wed, Jun 8, 2016 at 4:01 AM, Amit Kapila wrote: > > If we want to address both page level and tuple level inconsistencies, I > > could see below possibility. > > > > 1. An API that returns

Re: [HACKERS] Precedence of new phrase search tsquery operator

On Wed, Jun 8, 2016 at 7:13 PM, Tom Lane wrote: > It appears that the new <-> operator has been made to have exactly the > same grammatical precedence as the existing & (AND) operator. Thus, > for example, 'a & b <-> c'::tsquery means something different from > 'b <-> c &

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Thom Brown writes: > On 15 May 2014 at 19:56, Bruce Momjian wrote: >> On Tue, May 13, 2014 at 06:58:11PM -0400, Tom Lane wrote: >>> A recent question from Tim Kane prompted me to measure the overhead >>> costs of EXPLAIN ANALYZE, which I'd not checked in awhile.

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

Another thing I noticed: if you test with tsvectors that don't contain position info, <-> seems to reduce to &, that is it doesn't enforce relative position: regression=# select 'cat bat fat rat'::tsvector @@ 'cat <-> rat'::tsquery; ?column? -- t (1 row) regression=# select 'rat cat

[HACKERS] Use of index for 50% column restriction

As part of my research on the parsing/planning behavior of PREPARE, I found a surprising behavior --- a WHERE clause that is 50% restrictive is using an index. I thought only <10% restrictions used indexes. To setup the test: DROP TABLE IF EXISTS test; CREATE TABLE test (c1 INT,

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 8, 2016 at 9:40 AM, Kevin Grittner wrote: >>> Of course, ii_BrokenHotChain should be renamed to something like >>> ii_UnsafeForOldSnapshots, and some comments need to be updated; but >>> the above is the substance of it. >> >> I don't know why we'd want to rename it

Re: [HACKERS] Use of index for 50% column restriction

Bruce Momjian writes: > As part of my research on the parsing/planning behavior of PREPARE, I > found a surprising behavior --- a WHERE clause that is 50% restrictive > is using an index. I thought only <10% restrictions used indexes. There's no such hard-and-fast rule. The

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

On Wed, Jun 8, 2016 at 9:01 PM, Jean-Pierre Pelletier wrote: > If instead of casts, functions to_tsvector() and to_tsquery() are used, > then the results is (I think ?) as expected: because to_tsvector() function returns positions of words. > > select

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

On Wed, Jun 8, 2016 at 8:12 PM, Tom Lane wrote: > Another thing I noticed: if you test with tsvectors that don't contain > position info, <-> seems to reduce to &, that is it doesn't enforce > relative position: > > regression=# select 'cat bat fat rat'::tsvector @@ 'cat <->

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

On Wed, Jun 8, 2016 at 1:05 AM, Tom Lane wrote: > Jean-Pierre Pelletier writes: >> I wanted to test if phraseto_tsquery(), new with 9.6 could be used for >> matching consecutive words but it won't work for us if it cannot handle >> consecutive

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

Oleg Bartunov writes: > On Wed, Jun 8, 2016 at 1:05 AM, Tom Lane wrote: >> I concur that that seems like a rather useless behavior. If we have >> "x <-> y" it is not possible to match at distance zero, while if we >> have "x <-> x" it seems unlikely that

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

Oleg Bartunov writes: > On Wed, Jun 8, 2016 at 8:12 PM, Tom Lane wrote: >> Another thing I noticed: if you test with tsvectors that don't contain >> position info, <-> seems to reduce to &, that is it doesn't enforce >> relative position: > yes, that's

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 8, 2016 at 2:49 PM, Robert Haas wrote: > Do you have a test case that demonstrates a problem, or an explanation > of why you think there is one? With old_snapshot_threshold = '1min' -- connection 1 drop table if exists t1; create table t1 (c1 int not null);

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 8, 2016 at 4:04 PM, Kevin Grittner wrote: > On Wed, Jun 8, 2016 at 2:49 PM, Robert Haas wrote: >> Do you have a test case that demonstrates a problem, or an explanation >> of why you think there is one? > > With old_snapshot_threshold =

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 8, 2016 at 4:01 AM, Amit Kapila wrote: > If we want to address both page level and tuple level inconsistencies, I > could see below possibility. > > 1. An API that returns setof records containing a block that have > inconsistent vm bit, a block where visible

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/07/2016 05:44 PM, Robert Haas wrote: adminpack: Doesn't seem useful. The case I imagined was if someone would use these functions on the result from a slow CTE and would want the CTE to be executed in parallel. I have no idea if that is a realistic case, but I rarely use adminpack in

Re: [HACKERS] Declarative partitioning

0003-... patch does not apply cleanly. It has some conflicts in pg_dump.c. I have tried fixing the conflict in attached patch. On Mon, May 23, 2016 at 3:35 PM, Amit Langote wrote: > > Hi Ildar, > > On 2016/05/21 0:29, Ildar Musin wrote: > > On 20.05.2016 11:37,

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, Jun 7, 2016 at 10:40 AM, Robert Haas wrote: > On Sat, Jun 4, 2016 at 4:21 PM, Kevin Grittner wrote: >> the minimal patch to fix behavior in this area would be: >> >> diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c >> index

Re: [HACKERS] Rename max_parallel_degree?

On 06/07/2016 11:01 PM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 9:39 AM, Tom Lane wrote: >> Robert Haas writes: >>> I think we should just go with max_parallel_workers for a limit on >>> total parallel workers within max_work_processes, and >>>

Re: [HACKERS] Rename synchronous_standby_names?

At Fri, 3 Jun 2016 10:52:31 +0200, Vik Fearing wrote in <5751454f.6020...@2ndquadrant.fr> > On 01/06/16 02:49, Michael Paquier wrote: > > On Wed, Jun 1, 2016 at 3:56 AM, David G. Johnston > > wrote: > >> On Tue, May 31, 2016 at 2:19 PM, Peter

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 8, 2016 at 11:39 AM, Andres Freund wrote: > > On 2016-06-08 10:04:56 +0530, Amit Kapila wrote: > > On Tue, Jun 7, 2016 at 11:01 PM, Andres Freund wrote:> > > > I think if we go with the pg_check_visibility approach, we should also > > > copy

[HACKERS] If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back?

Hi, I'm researching the synchronous replication. I see the backend of the Primary Server calls SyncRepWaitForLSN() to wait for the Standby Server to write the WAL records. If some thing happens, such as network failure or disk failure, causes the Standby Server fail to receive WAL records or

Re: [HACKERS] If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back?

> Hi, > > I'm researching the synchronous replication. I see the backend of the > Primary Server calls SyncRepWaitForLSN() to wait for the Standby Server to > write the WAL records. > > If some thing happens, such as network failure or disk failure, causes the > Standby Server fail to receive

Re: [HACKERS] If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back?

On Wed, Jun 8, 2016 at 7:43 PM, Tatsuo Ishii wrote: >> Hi, >> >> I'm researching the synchronous replication. I see the backend of the >> Primary Server calls SyncRepWaitForLSN() to wait for the Standby Server to >> write the WAL records. >> >> If some thing happens, such as

Re: [HACKERS] parallel.c is not marked as test covered

On Tue, Jun 7, 2016 at 11:43 PM, Noah Misch wrote: > Committed that way. Thanks for the carefully-considered commit, Noah. And thanks Clement, Peter, and others involved in figuring out the best way to do this and drawing attention to it. -- Robert Haas EnterpriseDB:

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On 15 May 2014 at 19:56, Bruce Momjian wrote: > On Tue, May 13, 2014 at 06:58:11PM -0400, Tom Lane wrote: > > A recent question from Tim Kane prompted me to measure the overhead > > costs of EXPLAIN ANALYZE, which I'd not checked in awhile. Things > > are far worse than I

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On Tue, Jun 7, 2016 at 10:41 PM, Noah Misch wrote: > [Action required within 72 hours. This is a generic notification.] > > The above-described topic is currently a PostgreSQL 9.6 open item. Robert, > since you committed the patch believed to have created it, you own this

Re: [HACKERS] Typo in pg_visibility

On Tue, Jun 7, 2016 at 8:45 PM, Amit Langote wrote: > On 2016/06/08 9:38, Amit Langote wrote: >> Attached fixes a typo: >> >> s/PG_ALL_VISIBLE/PD_ALL_VISIBLE/g > > Oops. Made a couple of mistakes there: > > Subject: Typo in pg_visibility documentation > Patch:

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On 2016/06/08 14:13, Ashutosh Bapat wrote: > On Tue, Jun 7, 2016 at 6:19 PM, Amit Langote wrote: >> On Tue, Jun 7, 2016 at 7:47 PM, Ashutosh Bapat wrote: >>> Looks good to me. If we add a column from the outer relation, the >> "NULL"ness >>> of inner column would be more clear. May be we should

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On Wed, Jun 8, 2016 at 12:25 PM, Amit Langote wrote: > On 2016/06/08 14:13, Ashutosh Bapat wrote: > > On Tue, Jun 7, 2016 at 6:19 PM, Amit Langote wrote: > >> On Tue, Jun 7, 2016 at 7:47 PM, Ashutosh Bapat wrote: > >>> Looks good to me. If we add a column from the

Re: [HACKERS] slower connect from hostnossl clients

At Tue, 7 Jun 2016 12:18:31 +0200, Magnus Hagander wrote in > On Tue, Jun 7, 2016 at 11:31 AM, Pavel Stehule > wrote: > >> That's definitely not expected behavior. hostnossl should

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 8, 2016 at 12:19 PM, Amit Kapila wrote: > On Tue, Jun 7, 2016 at 10:10 PM, Masahiko Sawada > wrote: >> >> Thank you for implementing the patch. >> >> I've not test it deeply but here are some comments. >> This check tool only checks if

Re: [HACKERS] slower connect from hostnossl clients

2016-06-08 8:26 GMT+02:00 Kyotaro HORIGUCHI : > At Tue, 7 Jun 2016 12:18:31 +0200, Magnus Hagander > wrote in < > cabuevez5qrmq4ebysbz+ujfg_3_ap361zqtgbh_ef+2j6p0...@mail.gmail.com> > > On Tue, Jun 7, 2016 at 11:31 AM, Pavel Stehule

Re: [HACKERS] Reviewing freeze map code

On 2016-06-08 10:04:56 +0530, Amit Kapila wrote: > On Tue, Jun 7, 2016 at 11:01 PM, Andres Freund wrote:> > > I think if we go with the pg_check_visibility approach, we should also > > copy the other consistency checks from vacuumlazy.c, given they can't > > easily be

Re: [HACKERS] [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all

W dniu 2016-06-08 o 05:04, Tom Lane pisze: Jim Nasby writes: Is there any significant advantage to not analyzing all columns? Only case I can think of is if you have a fair number of columns that have been toasted; otherwise I'd think IO would completely swamp any

Re: [HACKERS] Use of index for 50% column restriction

On Wed, Jun 8, 2016 at 01:28:54PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > As part of my research on the parsing/planning behavior of PREPARE, I > > found a surprising behavior --- a WHERE clause that is 50% restrictive > > is using an index. I thought only <10%

Re: [HACKERS] Use of index for 50% column restriction

On Wed, Jun 8, 2016 at 05:07:34PM -0400, Bruce Momjian wrote: > > For randomly-ordered data I believe the cutover is actually well below 10%. > > Ah, I had not considered the correlation order of the rows in the table. > This test returns the sequential scan I expected by using floor(random() >

Re: [HACKERS] [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all

Tomasz Ostrowski writes: > W dniu 2016-06-08 o 05:04, Tom Lane pisze: >> Yeah, my guess is that the OP's example where analyzing just one column >> was significantly cheaper boiled down to some of the other columns being >> mostly toasted data. Otherwise it's hard to see

Re: [HACKERS] Parallel safety tagging of extension functions

On Wed, Jun 8, 2016 at 9:24 AM, Andreas Karlsson wrote: >> dblink: Isn't changing dblink_fdw_validator pointless? The others I get. > > Yeah, but since it is just one function I think it makes sense to change it > when we already are bumping the version of the extension. I

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On Wed, Jun 8, 2016 at 9:27 PM, Robert Haas wrote: > On Tue, Jun 7, 2016 at 10:41 PM, Noah Misch wrote: >> [Action required within 72 hours. This is a generic notification.] >> >> The above-described topic is currently a PostgreSQL 9.6 open item.

Re: [HACKERS] Rename max_parallel_degree?

Josh Berkus writes: > On 06/07/2016 11:01 PM, Robert Haas wrote: >> Here's a patch change max_parallel_degree to >> max_parallel_workers_per_gather, and also changing parallel_degree to >> parallel_workers. I haven't tackled adding a separate >> max_parallel_workers, at least

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

If instead of casts, functions to_tsvector() and to_tsquery() are used, then the results is (I think ?) as expected: select to_tsvector('simple', 'cat bat fat rat') @@ to_tsquery('simple', 'cat <-> rat'); or select to_tsvector('simple', 'rat cat bat fat') @@ to_tsquery('simple', 'cat <-> rat');

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Fri, Jun 03, 2016 at 04:29:40PM -0500, Kevin Grittner wrote: > On Fri, May 27, 2016 at 10:35 AM, Kevin Grittner wrote: > > On Tue, May 24, 2016 at 4:10 PM, Robert Haas wrote: > > >> [ANALYZE of index with expression may fail to update statistics > >>

Re: [HACKERS] Perf Benchmarking and regression.

On Sun, May 29, 2016 at 01:26:03AM -0400, Noah Misch wrote: > On Thu, May 12, 2016 at 10:49:06AM -0400, Robert Haas wrote: > > On Thu, May 12, 2016 at 8:39 AM, Ashutosh Sharma > > wrote: > > > Please find the test results for the following set of combinations taken > > >

Re: [HACKERS] ORDER/GROUP BY expression not found in targetlist

Hi, I got same error by TPC-H: Q1,4,8,12 and 17. I've attached results of the queries. TPC-H (thanks to Tomas Vondra) https://github.com/tvondra/pg_tpch Datasize Scale Factor: 1 PG96beta1 commit: f721e94b5f360391fc3ffe183bf697a0441e9184 Regards, Tatsuro Yamada NTT OSS Center On

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

On Mon, Jun 6, 2016 at 6:07 AM, Amit Kapila wrote: > That seems doable, as for such rels we can only have Vars and > PlaceHolderVars in targetlist. Basically, whenever we are adding > PlaceHolderVars to a relation, just remember that information and use it > later. The

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 8, 2016 at 6:31 PM, Robert Haas wrote: > > > Here's my proposal: > > 1. You already implemented a function to find non-frozen tuples on > supposedly all-frozen pages. Great. > > 2. Let's implement a second function to find dead tuples on supposedly >

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 8, 2016 at 10:18 AM, Tom Lane wrote: >>> Note that there is a dump/restore hazard if people have set the >>> parallel_degree reloption on a beta1 install, or used ALTER { USER | >>> DATABASE } .. SET parallel_degree. Can everybody live with that? >>> Should I bump

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas writes: > On Wed, Jun 8, 2016 at 10:18 AM, Tom Lane wrote: >> catversion is not relevant to GUC changes. It's not really necessary, >> because you'd get a clean, easily diagnosed and repaired failure during >> postmaster startup anyway.

Re: [HACKERS] hstore: add hstore_length function

On Mon, Jun 6, 2016 at 7:57 PM, Korbin Hoffman wrote: > With regards to your second point- I've been maintaining consistency > with the rest of the hstore module. Hstore's _size is internally > stored as a uint, but all uses of HS_COUNT across the feature end up > stored in a signed

Re: [HACKERS] Problem with dumping bloom extension

* Noah Misch (n...@leadboat.com) wrote: > Yep, pretty much that. CLOSE_WAIT is for performance defects, race > conditions, and other defects where a successful fix is difficult to verify > beyond reasonable doubt. Other things can move directly to "resolved". I > don't mind if practice diverges

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 8, 2016 at 10:41 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jun 8, 2016 at 10:18 AM, Tom Lane wrote: >>> catversion is not relevant to GUC changes. It's not really necessary, >>> because you'd get a clean,