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
> all-visible pages.
>
I am plannin
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 patch doing the same is at
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 201
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
> > > at
> > > 128 client coun
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
> >> if ANALYZE runs longer than old_snapshot_t
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 documented behaviour.
Oh? Where? I've be
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 the user is expecting us to
>> treat that
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()
> *
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% restrictions used index
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 *duplicate* words.
>
>> For example, the following re
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 <-> rat'::tsquery;
> ?col
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
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 to_tsvector('simple', 'cat bat fat rat') @@
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 = '1min'
>
> -- connection 1
> drop table if exist
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);
insert into t1 select gen
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 like that...
>
> If
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 cost estimate break
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,
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 ba
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 & a'::tsquery:
>
> regress
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 & a'::tsquery:
>
> regress
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
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 setof records containing a block that have
> > inc
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. Things
>>> are far worse than I t
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, easily diagnosed and repaired failure during
>>> postmaster startup
* 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
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 int. I could o
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. The point of bumping catversion is to prevent
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 catversion when appl
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 not yet. Are people
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. Robert,
>> since you committed the patch believe
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 think it makes
> sense
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 how there's much more
>>
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 31a1438..6c379da 100644
>> --- a/src/backe
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 m
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, Amit Langote wrote:
> >> Moreover,
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 page contains dead tuples
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
>>> max_parallel_workers_per_gather for a per-Gather
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: Really attached this time.
Thanks,
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 open
> item. If some o
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: http://www.enterprisedb.co
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 network failure or dis
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 thought. On my current
> 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
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 fail
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 Eisentraut
> >> wrote:
> >>>
> >>> On 5/31/16 1:47 P
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 the other consistency checks from vacuumlaz
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 outer relation, the
> >> "NULL"n
48 matches
Mail list logo
