> On 07 Sep 2017, at 09:30, Daniel Gustafsson wrote:
>
>> On 06 Sep 2017, at 07:13, David Rowley wrote:
>>
>> On 6 September 2017 at 00:43, Daniel Gustafsson wrote:
>>> This patch was moved to the currently open Commitfest. Given the above
>>> comment, is the last patch in this thread still u
> On 06 Sep 2017, at 07:13, David Rowley wrote:
>
> On 6 September 2017 at 00:43, Daniel Gustafsson wrote:
>> This patch was moved to the currently open Commitfest. Given the above
>> comment, is the last patch in this thread still up for review, or are you
>> working on a new version? Just t
On 6 September 2017 at 00:43, Daniel Gustafsson wrote:
> This patch was moved to the currently open Commitfest. Given the above
> comment, is the last patch in this thread still up for review, or are you
> working on a new version? Just to avoid anyone reviewing an outdated version.
Hi Daniel,
> On 09 Apr 2017, at 12:14, David Rowley wrote:
>
> On 8 April 2017 at 09:33, Claudio Freire wrote:
>> Otherwise, the patch LGTM, but I'd like to solve the quadratic
>> behavior too... are you going to try? Otherwise I could take a stab at
>> it myself. It doesn't seem very difficult.
>
> I ha
On 8 April 2017 at 09:33, Claudio Freire wrote:
> Otherwise, the patch LGTM, but I'd like to solve the quadratic
> behavior too... are you going to try? Otherwise I could take a stab at
> it myself. It doesn't seem very difficult.
I have some ideas in my head in a fairly generic way of solving th
On 4/7/17 5:33 PM, Claudio Freire wrote:
>
> Also, can you add a test case? Cost values could make the test
> fragile, so if that gives you trouble I'll understand, but it'd be
> best to try and test this if possible.
This submission has been moved to CF 2017-07.
--
-David
da...@pgmasters.net
On Fri, Apr 7, 2017 at 2:28 AM, David Rowley
wrote:
>> + if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound ==
>> DEFAULT_INEQ_SEL)
>> + {
>> + /* No point in checking null selectivity, DEFAULT_INEQ_SEL
>> implies we have no stats */
>> + s2 = DEFAULT_RANGE_INEQ_SEL;
>> + }
>> + el
On 4 April 2017 at 13:35, Claudio Freire wrote:
> On Mon, Apr 3, 2017 at 9:19 PM, Claudio Freire wrote:
> If you ask me, I'd just leave:
>
> + if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound ==
> DEFAULT_INEQ_SEL)
> + {
> + /* No point in checking null selectivity, DEFAULT_INEQ_SEL
On 7 April 2017 at 09:05, Claudio Freire wrote:
> On Tue, Apr 4, 2017 at 1:00 PM, Claudio Freire wrote:
If you ask me, I'd just leave:
+ if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound ==
DEFAULT_INEQ_SEL)
+ {
+ /* No point in checking null selectivity
On Tue, Apr 4, 2017 at 1:00 PM, Claudio Freire wrote:
>>> If you ask me, I'd just leave:
>>>
>>> + if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound ==
>>> DEFAULT_INEQ_SEL)
>>> + {
>>> + /* No point in checking null selectivity, DEFAULT_INEQ_SEL
>>> implies we have no stats */
>>> +
On Tue, Apr 4, 2017 at 8:21 AM, David Rowley
wrote:
> On 4 April 2017 at 13:35, Claudio Freire wrote:
>> On Mon, Apr 3, 2017 at 9:19 PM, Claudio Freire
>> wrote:
>>> On Mon, Apr 3, 2017 at 8:52 PM, David Rowley
>>> wrote:
> One last observation:
>
> +/*
> + * An
On Tue, Apr 4, 2017 at 8:12 AM, David Rowley
wrote:
> Result Comparison
>
> Master median tps Patch median tps comparison
> Test 1 6993.7 6714.3 104.16%
> Test 2 7053.1 6921.6 101.90%
> Test 3 5137.2 4954.2 103.69%
> Test 4 27.1 19.4 139.72%
> Test 5 54.1 51.4 105.28%
> Test 6 9328.1 9478.2 98.42%
On 3 April 2017 at 20:59, David Rowley wrote:
> Updated patch attached.
I did a little benchmarking on this to learn how planning time is affected.
Master = 9fa6e08d4a16f9b0461743cff35781e16308c106
Patched = 9fa6e08d4a16f9b0461743cff35781e16308c106 +
smarter_clausesel_2017-04-03.patch
Config:
On 4 April 2017 at 13:35, Claudio Freire wrote:
> On Mon, Apr 3, 2017 at 9:19 PM, Claudio Freire wrote:
>> On Mon, Apr 3, 2017 at 8:52 PM, David Rowley
>> wrote:
One last observation:
+/*
+ * An IS NOT NULL test is a no-op if there's any other strict
qua
On Mon, Apr 3, 2017 at 9:19 PM, Claudio Freire wrote:
> On Mon, Apr 3, 2017 at 8:52 PM, David Rowley
> wrote:
>>> One last observation:
>>>
>>> +/*
>>> + * An IS NOT NULL test is a no-op if there's any other strict
>>> quals,
>>> + * so if that's the case, then we'll only
On Mon, Apr 3, 2017 at 8:52 PM, David Rowley
wrote:
>> One last observation:
>>
>> +/*
>> + * An IS NOT NULL test is a no-op if there's any other strict quals,
>> + * so if that's the case, then we'll only apply this, otherwise
>> we'll
>> + * ignore it.
>> +
On 4 April 2017 at 11:35, Claudio Freire wrote:
> I'd prefer it if all occurrences of the concept were changed, to
> maintain consistency.
> That would include variables used to hold expressions that refer to
> these as well, as in the case of:
>
> +Node *var;
> +
> +
On Mon, Apr 3, 2017 at 5:59 AM, David Rowley
wrote:
>> +static void addCachedSelectivityRangeVar(CachedSelectivityClause
>> **cslist, Node *var,
>> bool varonleft, bool isLTsel, Selectivity s2);
>>
>> You're changing clause -> var throughout the code when dealing with
>> nodes, but
On Mon, Apr 3, 2017 at 6:22 PM, David Rowley
wrote:
> On 4 April 2017 at 08:24, Andres Freund wrote:
>> On 2017-04-03 20:59:42 +1200, David Rowley wrote:
>>> Updated patch attached.
>>>
>>> Thanks for reviewing it.
>>
>> Given the time in the release cycle I'm afraid that this it's too late
>> to
On 2017-04-04 09:22:07 +1200, David Rowley wrote:
> On 4 April 2017 at 08:24, Andres Freund wrote:
> > On 2017-04-03 20:59:42 +1200, David Rowley wrote:
> >> Updated patch attached.
> >>
> >> Thanks for reviewing it.
> >
> > Given the time in the release cycle I'm afraid that this it's too late
>
On 4 April 2017 at 08:24, Andres Freund wrote:
> On 2017-04-03 20:59:42 +1200, David Rowley wrote:
>> Updated patch attached.
>>
>> Thanks for reviewing it.
>
> Given the time in the release cycle I'm afraid that this it's too late
> to get this into v10. Does anybody disagree? If not, it should
On Mon, Apr 3, 2017 at 5:24 PM, Andres Freund wrote:
> On 2017-04-03 20:59:42 +1200, David Rowley wrote:
>> Updated patch attached.
>>
>> Thanks for reviewing it.
>
> Given the time in the release cycle I'm afraid that this it's too late
> to get this into v10. Does anybody disagree? If not, it
On 2017-04-03 20:59:42 +1200, David Rowley wrote:
> Updated patch attached.
>
> Thanks for reviewing it.
Given the time in the release cycle I'm afraid that this it's too late
to get this into v10. Does anybody disagree? If not, it should be
moved to the next CF.
Greetings,
Andres Freund
--
On 1 April 2017 at 16:42, Claudio Freire wrote:
>
> I thought to take a quick look at this patch. I'll probably take a
> deeper look later, but some initial comments:
>
> -typedef struct RangeQueryClause
> +typedef struct CachedSelectivityClause
> {
> -struct RangeQueryClause *next;/*
On Fri, Feb 24, 2017 at 7:00 AM, David Rowley
wrote:
> I've stumbled over an interesting query out in the wild where the
> query was testing a nullable timestamptz column was earlier than some
> point in time, and also checking the column IS NOT NULL.
>
> The use pattern here was that records whic
David Steele writes:
> Anyone familiar with the planner available to review this patch?
FWIW, it's on my radar but I don't expect to get to it real soon,
as there's other stuff I deem higher priority. In the meantime,
I don't want to stand in the way of someone else looking at it.
On 2/26/17 1:41 AM, Robert Haas wrote:
> On Fri, Feb 24, 2017 at 3:30 PM, David Rowley
> wrote:
>> It would be good to improve the situation here in the back branches
>> too, but I'm thinking that the attached might be a little invasive for
>> that?
>
> My experience has been that customers - at
On Fri, Feb 24, 2017 at 3:30 PM, David Rowley
wrote:
> It would be good to improve the situation here in the back branches
> too, but I'm thinking that the attached might be a little invasive for
> that?
My experience has been that customers - at least EnterpriseDB
customers - do not appreciate p
I've stumbled over an interesting query out in the wild where the
query was testing a nullable timestamptz column was earlier than some
point in time, and also checking the column IS NOT NULL.
The use pattern here was that records which required processing had
this timestamp set to something other
29 matches
Mail list logo
