On Mon, Oct 16, 2017 at 2:36 AM, David Rowley
wrote:
> I personally think it's great we're starting to see a useful feature
> materialise that can help with poor row estimates from the planner.
I agree. My original post to this thread was more of a throw-away
comment than anything, and I'm not a
On 15 October 2017 at 06:49, Robert Haas wrote:
> On Fri, Oct 13, 2017 at 4:49 PM, David Rowley
> wrote:
>> tps = 8282.481310 (including connections establishing)
>> tps = 8282.750821 (excluding connections establishing)
>
> vs.
>
>> tps = 8520.822410 (including connections establishing)
>> tps =
On 10/14/2017 07:49 PM, Robert Haas wrote:
> On Fri, Oct 13, 2017 at 4:49 PM, David Rowley
> wrote:
>> tps = 8282.481310 (including connections establishing)
>> tps = 8282.750821 (excluding connections establishing)
>
> vs.
>
>> tps = 8520.822410 (including connections establishing)
>> tps = 8
On Fri, Oct 13, 2017 at 4:49 PM, David Rowley
wrote:
> tps = 8282.481310 (including connections establishing)
> tps = 8282.750821 (excluding connections establishing)
vs.
> tps = 8520.822410 (including connections establishing)
> tps = 8521.132784 (excluding connections establishing)
>
> With th
On Fri, Oct 13, 2017 at 4:44 PM, Tomas Vondra
wrote:
> 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
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 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 13 October 2017 at 04:56, Alvaro Herrera wrote:
> I pushed your original fix.
Thanks for committing
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On 13 October 2017 at 02:17, Alvaro Herrera wrote:
> I propose this slightly larger change.
hmm, this is not right. You're not checking that there's a Var below
the RelabelType.
I tried with:
explain select * from ab where (a||a)::varchar = '' and b = '';
and your code assumed the OpExpr was a
Basically, $subject is causing us not to properly find matching
extended stats in this case.
The attached patch fixes it.
The following test cases is an example of the misbehaviour. Note
rows=1 vs rows=98 in the Gather node.
create table ab (a varchar, b varchar);
insert into ab select (x%1000):
11 matches
Mail list logo
