Hello Robert,
Mmph. I understand the desire to identify the exact commit used for a
build somehow, but something whose output depends on whether or not I
left a branch lying around locally doesn't seem that great.
Indeed, the branch/tag search might have a little strange behavior.
Probably
I upgraded one of our customers to PG10 Tuesday night, and Wednesday replaced
an BTREE index with BRIN index (WITH autosummarize).
Today I see:
< 2017-10-13 17:22:47.839 -04 >LOG: server process (PID 32127) was terminated
by signal 11: Segmentation fault
< 2017-10-13 17:22:47.839 -04 >DETAIL:
On Mon, Oct 09, 2017 at 05:19:11PM -0700, Peter Geoghegan wrote:
> On Sun, Oct 16, 2016 at 6:46 PM, Noah Misch wrote:
> > - Verify agreement between CLOG, MULTIXACT, and hint bits.
>
> This is where it gets complicated, I think. This is what I really want
> to talk about.
>
> The recent commit 2
On 2017-10-13 16:31:37 -0700, Joe Conway wrote:
> On 09/17/2017 11:29 PM, Andres Freund wrote:
> > On 2017-09-18 07:24:43 +0100, Simon Riggs wrote:
> >> On 18 September 2017 at 05:50, Andres Freund wrote:
> >> > Hi,
> >> >
> >> > Just noticed that we're returning the underlying values for
> >> > p
On Sat, Oct 14, 2017 at 4:47 AM, Robert Haas wrote:
> Mmph. I understand the desire to identify the exact commit used for a
> build somehow, but something whose output depends on whether or not I
> left a branch lying around locally doesn't seem that great.
Similarly to Peter, I prefer a minimum
On 09/17/2017 11:29 PM, Andres Freund wrote:
> On 2017-09-18 07:24:43 +0100, Simon Riggs wrote:
>> On 18 September 2017 at 05:50, Andres Freund wrote:
>> > Hi,
>> >
>> > Just noticed that we're returning the underlying values for
>> > pg_control_recovery() without any checks:
>> > postgres[14388][
On Sat, Oct 14, 2017 at 11:27 AM, Thomas Munro
wrote:
> On Sat, Oct 14, 2017 at 7:47 AM, legrand legrand
> wrote:
>> Is it stored somewhere to permit to users like me
>> that want to test pg 10 on windows
>> without having to build it ?
Erm, wait, you said pg 10. That's already released. This
I wrote:
> Moving on to the exact color of the bikeshed: it seems like the right
> way to present this to users of CREATE AGGREGATE is in terms of "does
> the final function modify the transition state?". So maybe the values
> could be spelled
> SMODIFY = READ_ONLY ffunc never touches state, ok
I want to get the join graph of a given query. Which has node for each
relation and an edge between two nodes if they have a join predicate among
them.
On 14-Oct-2017 3:58 AM, "Andres Freund" wrote:
> On 2017-10-14 03:49:57 +0530, Gourav Kumar wrote:
> > But then is there some way to tell Optimiz
On 2017-10-14 03:49:57 +0530, Gourav Kumar wrote:
> But then is there some way to tell Optimizer not to consider transitive
> joins ?
What are you actually trying to achieve here?
- Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On Sat, Oct 14, 2017 at 7:47 AM, legrand legrand
wrote:
> This may seems obvious for you
>
> but where is the build result ?
Each CI platform has a web page corresponding to your
GitHub/BitBucket/... user account that lists builds results. You can
also get notifications by various means includin
But then is there some way to tell Optimizer not to consider transitive
joins ?
Or to know if the join is transitive or not ?
On 14-Oct-2017 3:43 AM, "Tom Lane" wrote:
> Gourav Kumar writes:
> > For e.g. I am checking for this query
> > ...
> > where
> > and ss1.ca_county = ss2.ca_county
>
Gourav Kumar writes:
> For e.g. I am checking for this query
> ...
> where
> and ss1.ca_county = ss2.ca_county
> and ss2.ca_county = ss3.ca_county
> and ss1.ca_county = ws1.ca_county
> and ws1.ca_county = ws2.ca_county
> and ws1.ca_county = ws3.ca_county
> It doesn't has a jo
Hi,
On 2017-10-14 10:38:13 +1300, David Rowley wrote:
> On 12 October 2017 at 04:50, Robert Haas wrote:
> > We haven't really done a very good job figuring out what to do about
> > optimizations that some people (mostly you) think are marginal. It's
> > obviously true that we can't just burn inf
Why does have_relevant_joinclause() and have_relevant_eclass_joinclause()
return true for all possible joins for the query given below.
Even when they have no join predicate between them.
e.g. join between ss1 & ws3, ss2 & ws3 etc.
The query is :
TPC-DS query 50
-- query 50 in stream 0 using tem
On 12 October 2017 at 04:50, Robert Haas wrote:
> We haven't really done a very good job figuring out what to do about
> optimizations that some people (mostly you) think are marginal. It's
> obviously true that we can't just burn infinite planner cycles on
> things that don't usually help, but a
Hi,
On 2017-10-13 10:38:47 -0700, Andres Freund wrote:
> On 2017-10-13 13:06:41 -0400, Robert Haas wrote:
> > On Thu, Sep 14, 2017 at 2:12 AM, Andres Freund wrote:
> > > This patch gives me roughly 8% speedup in a workload that consists out
> > > of a fast query that returns a lot of columns. If
For e.g. I am checking for this query
with ss as
(select ca_county,d_qoy, d_year,sum(ss_ext_sales_price) as store_sales
from store_sales,date_dim,customer_address
where ss_sold_date_sk = d_date_sk
and ss_addr_sk=ca_address_sk
group by ca_county,d_qoy, d_year),
ws as
(select ca_county,d_qoy
I tried debugging the code, at no point in execution the function
make_rels_by_clauseless_joins
was called. Although optimizer did consider some of the joins which are
cross products.
On 14 October 2017 at 01:57, Gourav Kumar wrote:
> Can I use something like joininfo, which will store the joi
On 14 October 2017 at 09:04, Robert Haas wrote:
> On Mon, Oct 9, 2017 at 11:03 PM, David Rowley
> wrote:
>> -- Unpatched
>> Planning time: 0.184 ms
>> Execution time: 105.878 ms
>>
>> -- Patched
>> Planning time: 2.175 ms
>> Execution time: 106.326 ms
>
> This might not be the best example to
On 10/13/2017 10:04 PM, Robert Haas wrote:
> On Mon, Oct 9, 2017 at 11:03 PM, David Rowley
> wrote:
>> -- Unpatched
>> Planning time: 0.184 ms
>> Execution time: 105.878 ms
>>
>> -- Patched
>> Planning time: 2.175 ms
>> Execution time: 106.326 ms
>
> This might not be the best example to sho
On Fri, Oct 13, 2017 at 1:02 PM, Robert Haas wrote:
>> I don't think it's our place to "interpret" the bits. Are we *also*
>> going to show HEAP_XMIN_FROZEN when xmin is physically set to
>> FrozenTransactionId?
>
> No, of course not. We're talking about how to display the 256 and 512
> bits of t
Can I use something like joininfo, which will store the join predicates and
I can check if there is no join predicate among the two relations don't
consider them.
On 14 October 2017 at 01:48, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> On Fri, Oct 13, 2017 at 5:08 PM, Robert Haa
On Fri, Oct 13, 2017 at 1:19 AM, Amit Kapila wrote:
> After fixing this problem, when I ran the regression tests with
> force_parallel_mode = regress, I saw multiple other failures. All the
> failures boil down to two kinds of cases:
>
> 1. There was an assumption while extracting simple expressi
On Fri, Oct 13, 2017 at 5:08 PM, Robert Haas wrote:
>
> On Fri, Oct 13, 2017 at 4:06 PM, Gourav Kumar
wrote:
> > Can you guide me where to look for it?
>
> Search for make_rels_by_clauseless_joins.
>
I wonder if it's possible implement it as an extension using some hook
--
Fabrízio de Royes Mel
On Fri, Oct 13, 2017 at 4:06 PM, Gourav Kumar wrote:
> Can you guide me where to look for it?
Search for make_rels_by_clauseless_joins.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
Can you guide me where to look for it?
On 14 October 2017 at 01:35, Robert Haas wrote:
> On Fri, Oct 13, 2017 at 3:41 PM, Gourav Kumar
> wrote:
> > is there some way through which I can disable cross products in
> postgresql?
> >
> > This will make the DP join to not to consider join between tw
On Fri, Oct 13, 2017 at 3:41 PM, Gourav Kumar wrote:
> is there some way through which I can disable cross products in postgresql?
>
> This will make the DP join to not to consider join between two relations if
> they don't have a join predicate among them.
I mean, it would be easy enough to modi
On Mon, Oct 9, 2017 at 11:03 PM, David Rowley
wrote:
> -- Unpatched
> Planning time: 0.184 ms
> Execution time: 105.878 ms
>
> -- Patched
> Planning time: 2.175 ms
> Execution time: 106.326 ms
This might not be the best example to show the advantages of the
patch, honestly.
--
Robert Haas
E
On Thu, Oct 12, 2017 at 7:35 PM, Peter Geoghegan wrote:
> On Tue, Aug 15, 2017 at 10:54 AM, Robert Haas wrote:
>>> Or at least make the filtering optional.
>>
>> I don't think "filtering" is the right way to think about it. It's
>> just labeling each combination of bits with the meaning appropri
On Thu, Oct 12, 2017 at 4:50 PM, Fabien COELHO wrote:
> "svnversion" adds a "M" for modified on the status. There is an option with
> "git describe" to get something similar:
>
> git describe --long --always --all --dirty
I tried this out a bit:
[rhaas pgsql]$ git describe --long --always --
Hi all,
is there some way through which I can disable cross products in postgresql?
This will make the DP join to not to consider join between two relations if
they don't have a join predicate among them.
Thanks,
Gourav Kumar
Computer Science and Automation
Indian Institute of Science
On Fri, Oct 13, 2017 at 9:41 PM, Robert Haas wrote:
> On Fri, Oct 13, 2017 at 1:59 PM, Peter Geoghegan wrote:
> >> Fully agreed.
> >
> > If we implement that interface, where does that leave EvalPlanQual()?
>
>From the first glance, it seems that pluggable storage should
override EvalPlanQualFe
On Fri, Oct 13, 2017 at 12:38 PM, Alvaro Herrera
wrote:
> The relkind check in DefineIndex has grown into an ugly rats nest of
> 'if' statements. I propose to change it into a switch, as per the
> attached.
wfm
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On Fri, Oct 13, 2017 at 12:34 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> Implement table partitioning.
>
>> Currently, tables can be range-partitioned or list-partitioned. List
>> partitioning is limited to a single column, but range partitioning can
>> involve multiple columns. A partiti
The relkind check in DefineIndex has grown into an ugly rats nest of
'if' statements. I propose to change it into a switch, as per the
attached.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 1a7420321f7f4
Robert Haas wrote:
> Implement table partitioning.
> Currently, tables can be range-partitioned or list-partitioned. List
> partitioning is limited to a single column, but range partitioning can
> involve multiple columns. A partitioning "column" can be an
> expression.
I find the "partition st
On Thu, Oct 12, 2017 at 9:14 AM, Dilip Kumar wrote:
>> Yep, this fixes the failures for me.
>>
> Thanks for confirming.
Committed and back-patched to v10.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-
On Fri, Oct 13, 2017 at 9:37 PM, Robert Haas wrote:
> On Fri, Oct 13, 2017 at 5:25 AM, Kuntal Ghosh
> wrote:
> > For some other
> > storage engine, if we maintain the older version in different storage,
> > undo for example, and don't require a new index entry, should we still
> > call it HOT-ch
This may seems obvious for you
but where is the build result ?
Is it stored somewhere to permit to users like me
that want to test pg 10 on windows
without having to build it ?
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
--
Sent via pgsq
On Fri, Oct 13, 2017 at 1:59 PM, Peter Geoghegan wrote:
>> Fully agreed.
>
> If we implement that interface, where does that leave EvalPlanQual()?
> Do those semantics have to be preserved?
For a general-purpose heap storage format, I would say yes.
I mean, we don't really have control over how
On Fri, Oct 13, 2017 at 5:25 AM, Kuntal Ghosh
wrote:
> For some other
> storage engine, if we maintain the older version in different storage,
> undo for example, and don't require a new index entry, should we still
> call it HOT-chain?
I would say, emphatically, no. HOT is a creature of the exi
Andres Freund writes:
> On 2017-10-13 14:07:54 -0400, Tom Lane wrote:
>> One idea might be to see if we can precalculate all the control data
>> needed for the caches and set it up as compile-time constants,
>> a la Gen_fmgrtab.pl, rather than reading it from the catalogs during
>> startup. That
On 2017-10-13 14:07:54 -0400, Tom Lane wrote:
> One idea might be to see if we can precalculate all the control data
> needed for the caches and set it up as compile-time constants,
> a la Gen_fmgrtab.pl, rather than reading it from the catalogs during
> startup. That would make the code less depe
On Fri, Oct 6, 2017 at 5:07 PM, Badrul Chowdhury wrote:
> I added a mechanism to fall back to v3.0 if the BE fails to start when FE
> initiates a connection with v3.1 (with optional startup parameters). This
> completely eliminates the need to backpatch older servers, ie newer FE can
> connect
Andres Freund writes:
> On 2017-10-13 13:06:41 -0400, Robert Haas wrote:
>> I don't think it's this patch's job to do it, but it seems like we
>> ought to just invent some early-initialization step where things like
>> this can happen, so that we don't have to branch here at all.
> Yea, that'd be
On Thu, Oct 12, 2017 at 2:23 PM, Robert Haas wrote:
> On Thu, Oct 12, 2017 at 4:38 PM, Alexander Korotkov
>> However I imply that alternative storage would share our "MVCC model". So,
>> it
>> should share our transactional model including transactions,
>> subtransactions, snapshots etc.
>> There
Hi,
On 2017-10-13 13:06:41 -0400, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 2:12 AM, Andres Freund wrote:
> > This patch gives me roughly 8% speedup in a workload that consists out
> > of a fast query that returns a lot of columns. If I apply a few
> > other performance patches, this patch it
On 10/12/2017 05:50 PM, Joshua D. Drake wrote:
-Hackers,
Bumping this.
I had a long call with a firm developing front end proxy/cache/HA for
Postgres today. Essentially the software is a replacement for PGPool in
entirety but also supports analytics etc... When I was asking them about
pai
On Fri, Oct 13, 2017 at 12:56 PM, Tom Lane wrote:
> It's better ... but after reading the patched code, a lot of my remaining
> beef is with the lack of clarity of the comments. You need ESP to
> understand what the function is trying to accomplish and what the
> constraints are. I'll take a wha
On Thu, Sep 14, 2017 at 2:12 AM, Andres Freund wrote:
> This patch gives me roughly 8% speedup in a workload that consists out
> of a fast query that returns a lot of columns. If I apply a few
> other performance patches, this patch itself starts to make a bigger
> difference, of around 11%.
I d
So from following this discussion and others focused on making the
planner "smarter", there is always an argument to be had over wasting
planner cycles, and it's always a hard fought battle to get any changes made.
Now, i'm speaking without any knowledge of the Postgres internals, so
please bear w
Robert Haas writes:
> On Fri, Oct 13, 2017 at 5:57 AM, Amit Khandekar
> wrote:
>> One thing we can do is : instead of calling
>> map_variable_attnos_mutator(), convert the var inside the if block for
>> "if (IsA(node, ConvertRowtypeExpr))". Please check the attached patch.
>> There, I have avoid
On Fri, Oct 13, 2017 at 4:54 AM, Robert Haas wrote:
> I haven't really followed this thread in depth, but I'm very nervous
> about the idea that we should ever be examining the raw-xmin of a
> tuple that has been marked HEAP_XMIN_FROZEN for anything other than
> forensic purposes.
I'm nervous abo
Heikki Linnakangas writes:
> We've been doing that window agg thing for a long time, so I think
> "works as window agg" should be the default for regular aggregates. For
> ordered-set aggregates, "no merging, no more transfn() calls after
> finalfn()" seems safest.
> It's a bit of a shame to h
On Fri, Oct 13, 2017 at 5:57 AM, Amit Khandekar wrote:
> One thing we can do is : instead of calling
> map_variable_attnos_mutator(), convert the var inside the if block for
> "if (IsA(node, ConvertRowtypeExpr))". Please check the attached patch.
> There, I have avoided coerced_var context variabl
On Wed, Oct 11, 2017 at 7:27 PM, Robert Haas wrote:
> On Wed, Oct 11, 2017 at 11:51 AM, Simon Riggs
> wrote:
> > I'm inclined to believe Robert's hypothesis that there is some race
> > condition there.
> >
> > The question is whether that still constitutes a serializability
> > problem since we
Noah Misch writes:
> I hacked psql to call PQtrace() and ran "psql -Xc 'select true'" in the
> defective configuration and in a working x64 GNU/Linux configuration. I've
> attached both PQtrace() products.
Thanks. It looks to me like the xlc build simply forgets to send some
of the T-message fi
On 10/13/2017 08:09 AM, Thomas Munro wrote:
> On Fri, Oct 13, 2017 at 1:42 PM, Andrew Dunstan
> wrote:
>> Well, as you can see here the appveyor.yml file can live outside the
>> tree that's being built.
> Here's a Wiki page where I hope we can collect how-to information on
> this general topic:
Heikki Linnakangas writes:
> On 10/13/2017 02:08 AM, Tom Lane wrote:
>> I started to look into fixing orderedsetaggs.c so that we could revert
>> 52328727b, and soon found a rather nasty problem. Although the plain
>> OSAs seem amenable to supporting multiple finalfn calls on the same
>> transiti
On Fri, Oct 6, 2017 at 3:59 AM, Amit Langote
wrote:
> On 2017/10/05 22:28, Erik Rijkers wrote:
> > In the 'ftp' listing, v10 appears at the bottom:
> > https://www.postgresql.org/ftp/source/
> >
> > With all the other v10* directories at the top, we could get a lot of
> > people installing wron
On 2017-10-13 16:37, Alexey Chernyshov wrote:
Hi all,
I am extending phrase operator is such way that it will have
syntax that means from n to m words, so I will use such syntax ()
further. I found that a AROUND(N) b is exactly the same as a <-N,N> b
and it can be replaced while parsing. So, wh
Hi all,
I am extending phrase operator is such way that it will have
syntax that means from n to m words, so I will use such syntax ()
further. I found that a AROUND(N) b is exactly the same as a <-N,N> b
and it can be replaced while parsing. So, what do you think of such
idea? In this patch I ha
On 10/13/2017 01:04 AM, Noah Misch wrote:
> On Fri, Oct 06, 2017 at 05:57:24PM +0800, Craig Ringer wrote:
>> On 6 October 2017 at 14:03, Noah Misch wrote:
>>> On Fri, Sep 08, 2017 at 10:32:03PM -0400, Tom Lane wrote:
(I do kinda wonder why we rolled our own RecursiveCopy; surely there's
>>>
On Fri, Oct 13, 2017 at 1:42 PM, Andrew Dunstan
wrote:
> Well, as you can see here the appveyor.yml file can live outside the
> tree that's being built.
Here's a Wiki page where I hope we can collect how-to information on
this general topic:
https://wiki.postgresql.org/wiki/Continuous_Integratio
On Thu, Oct 12, 2017 at 7:31 PM, Alvaro Herrera wrote:
>> Wouldn't this last "if" test, to cover the pg_upgrade case, be better
>> targeted by comparing *raw* xmin to FrozenTransactionId? You're using
>> the potentially distinct xmin value returned by
>> HeapTupleHeaderGetXmin() for the test here.
On 13 October 2017 at 09:13, Masahiko Sawada wrote:
> On Thu, Oct 12, 2017 at 11:30 PM, Robert Haas wrote:
>> On Thu, Oct 12, 2017 at 6:55 AM, Petr Jelinek
>> wrote:
>>> Thanks for the patch, looks correct to me.
>>
>> Committed and back-patched to v10.
Well spotted both of you!
Shows that rea
Bringing here the mail thread from pgsql-committers regarding this commit :
commit 1c497fa72df7593d8976653538da3d0ab033207f
Author: Robert Haas
Date: Thu Oct 12 17:10:48 2017 -0400
Avoid coercing a whole-row variable that is already coerced.
Marginal efficiency and beautification hac
On Fri, Oct 13, 2017 at 1:58 PM, Haribabu Kommi
wrote:
>
>
> On Fri, Oct 13, 2017 at 11:55 AM, Robert Haas wrote:
>>
>> On Thu, Oct 12, 2017 at 8:00 PM, Haribabu Kommi
>> wrote:
>>
>> That seems like a strange choice of API. I think it should more
>> integrated with the scan logic. For example
On 10/13/2017 02:41 AM, Tom Lane wrote:
David Rowley writes:
On 13 October 2017 at 12:08, Tom Lane wrote:
Therefore, I think we need to bite the bullet and provide an aggregate
property (CREATE AGGREGATE argument / pg_aggregate column) that tells
whether the aggregate supports transition stat
On Thu, 12 Oct 2017 13:11:45 +0900 (JST)
Tatsuo Ishii wrote:
> >> test=# CREATE VIEW v3 AS SELECT count(*) FROM v1;
> >> CREATE VIEW
> >> test=# BEGIN;
> >> BEGIN
> >> test=# LOCK TABLE v3;
> >> ERROR: cannot lock view "v3"
> >> DETAIL: Views that return aggregate functions are not automaticall
On Thu, Oct 12, 2017 at 11:30 PM, Robert Haas wrote:
> On Thu, Oct 12, 2017 at 6:55 AM, Petr Jelinek
> wrote:
>> Thanks for the patch, looks correct to me.
>
> Committed and back-patched to v10.
>
Thank you!
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source
On Fri, Oct 13, 2017 at 11:55 AM, Robert Haas wrote:
> On Thu, Oct 12, 2017 at 8:00 PM, Haribabu Kommi
> wrote:
> > Currently I added a snapshot_satisfies API to find out whether the tuple
> > satisfies the visibility or not with different types of visibility
> routines.
> > I feel these
> > are
Stephen Frost wrote:
> * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > Robert Haas wrote:
> > > One trick that some system use is avoid replanning as much as we do
> > > by, for example, saving plans in a shared cache and reusing them even
> > > in other sessions. That's hard to do in our arc
On 10/13/2017 02:08 AM, Tom Lane wrote:
I started to look into fixing orderedsetaggs.c so that we could revert
52328727b, and soon found a rather nasty problem. Although the plain
OSAs seem amenable to supporting multiple finalfn calls on the same
transition state, the "hypothetical set" functio
On 13 October 2017 at 19:36, Jeevan Chalke
wrote:
> I have tried exactly same tests to get to this factor on my local developer
> machine. And with parallelism enabled I got this number as 7.9. However, if
> I disable the parallelism (and I believe David too disabled that), I get
> this number as
76 matches
Mail list logo
