Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

David Rowley wrote: > On 19 January 2018 at 16:00, Kyotaro HORIGUCHI > wrote: > > And I'd like to ask David to check out his mail environment so > > that SPF record is available for his message. > > Will investigate This should be fixed now. Please let us know

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 23 January 2018 at 23:22, Amit Langote wrote: > On 2018/01/23 15:44, David Rowley wrote: >> Attached is what I had in mind about how to do this. > > Thanks for the delta patch. I will start looking at it tomorrow. Thanks. I've been looking more at this and I've

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi Amit , On 19 January 2018 at 04:03, David Rowley wrote: > On 18 January 2018 at 23:56, Amit Langote > wrote: >> So, I've been assuming that the planner changes in the run-time pruning >> patch have to do with selecting clauses

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 19 January 2018 at 16:00, Kyotaro HORIGUCHI wrote: > And I'd like to ask David to check out his mail environment so > that SPF record is available for his message. Will investigate -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

ail now has > Subject: Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender > Address Forgery]Re: [HACKERS] path toward faster partition pruning > as its subject, whereas the mail you're replying to only had > Subject: Re: [Sender Address Forgery]Re: [Sender Address Forgery

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi Amit, It seems your mail system continually adds "[Sender Address Forgery]" prefixes to messages. E.g. this mail now has Subject: Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning as its subjec

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 18 January 2018 at 23:56, Amit Langote wrote: >> I've not fully worked out how run-time pruning >> will use this as it'll need another version of >> get_partitions_from_clauses but passes in a PartScanClauseInfo >> instead, and does not call

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 18 January 2018 at 00:13, David Rowley wrote: > On 17 January 2018 at 23:48, Amit Langote wrote: >> I'm concerned that after your patch to remove >> match_clauses_to_partkey(), we'd be doing more work than necessary in >> some cases. For

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 17 January 2018 at 23:48, Amit Langote wrote: > I'm concerned that after your patch to remove > match_clauses_to_partkey(), we'd be doing more work than necessary in > some cases. For example, consider the case of using run-time pruning > for nested loop where the

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi David. On Wed, Jan 17, 2018 at 6:19 PM, David Rowley wrote: > On 17 January 2018 at 17:05, David Rowley > wrote: >> 6. Which brings me to; why do we need match_clauses_to_partkey at all? >> classify_partition_bounding_keys seems to

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 17 January 2018 at 17:05, David Rowley wrote: > 6. Which brings me to; why do we need match_clauses_to_partkey at all? > classify_partition_bounding_keys seems to do all the work > match_clauses_to_partkey does, plus more. Item #3 above is caused by > an

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 16 January 2018 at 21:08, Amit Langote wrote: > Attached v20. Thanks again. Thanks for working on v20. I've had a look over part of it and I've written down the following: 1. The following comment is not correct /* * Equality look up key. Values in the

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 16 January 2018 at 21:08, Amit Langote wrote: > On 2018/01/12 12:30, David Rowley wrote: >> 8. The code in get_partitions_from_ne_clauses() does perform quite a >> few nested loops. I think a more simple way to would be to track the >> offsets you've seen in a

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On Thu, Jan 11, 2018 at 10:30 PM, David Rowley wrote: > Instead, can you make it: > > if (keys->n_eqkeys > 0 || keys->n_minkeys > 0 || > keys->n_maxkeys > 0 || n_keynullness > 0) > return true; > > return false; Or better yet: return (keys->n_eqkeys > 0 ||

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

David, On 2018/01/12 12:30, David Rowley wrote: > Can you also perform a self-review of the patch? Some of the things > I'm picking up are leftovers from a previous version of the patch. We > might never get through this review if you keep leaving those around! Sorry, I will look more closely

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 12 January 2018 at 15:27, Amit Langote wrote: > On 2018/01/11 19:23, David Rowley wrote: >> ERROR: operator 531 is not a member of opfamily 1976 > > You'll be able to see that the error no longer appears with the attached > updated set of patches, but I'm now