Ok, will do that. Thanks a lot.
On Wed, Sep 5, 2018 at 9:37 PM Jeff Janes wrote:
>
>
> On Wed, Sep 5, 2018 at 12:00 PM Jeff Janes wrote:
>
>> On Wed, Sep 5, 2018 at 12:21 AM Dinesh Kumar wrote:
>>
>>> Hi All,
>>> I was wondering whether the case is solved or still continuing. As a
>>> Postgres
On Wed, Sep 5, 2018 at 12:00 PM Jeff Janes wrote:
> On Wed, Sep 5, 2018 at 12:21 AM Dinesh Kumar wrote:
>
>> Hi All,
>> I was wondering whether the case is solved or still continuing. As a
>> Postgres newbie, I can't understand any of the terms (JIT, tuple
>> deformation) as you mentioned above.
On Wed, Sep 5, 2018 at 12:21 AM Dinesh Kumar wrote:
> Hi All,
> I was wondering whether the case is solved or still continuing. As a
> Postgres newbie, I can't understand any of the terms (JIT, tuple
> deformation) as you mentioned above. Please anyone let me know , what is
> the current scenario
Hi All,
I was wondering whether the case is solved or still continuing. As a
Postgres newbie, I can't understand any of the terms (JIT, tuple
deformation) as you mentioned above. Please anyone let me know , what is
the current scenario.
Thanks,
Dineshkumar.
On Wed, Aug 1, 2018 at 8:51 PM Jeff Jan
On Mon, Jul 30, 2018 at 3:02 PM, Andres Freund wrote:
> Hi,
>
> On 2018-07-30 13:31:33 -0400, Jeff Janes wrote:
> > I don't know where the time is going with the as-committed JIT. None of
> > the JIT-specific timings reported by EXPLAIN (ANALYZE) add up to anything
> > close to the slow-down I'm
Hi,
On 2018-07-31 12:56:26 -0400, Jeff Janes wrote:
> On Mon, Jul 30, 2018 at 1:23 PM, Andres Freund wrote:
>
> > On 2018-07-30 07:19:07 -0400, Jeff Janes wrote:
> >
> > > And indeed, in my hands JIT makes it almost 3 times worse.
> >
> > Not in my measurement. Your example won't use JIT at all,
On Mon, Jul 30, 2018 at 1:23 PM, Andres Freund wrote:
> On 2018-07-30 07:19:07 -0400, Jeff Janes wrote:
>
> > And indeed, in my hands JIT makes it almost 3 times worse.
>
> Not in my measurement. Your example won't use JIT at all, because it's
> below the cost threshold. So I think you might just
Hi,
On 2018-07-30 13:31:33 -0400, Jeff Janes wrote:
> I don't know where the time is going with the as-committed JIT. None of
> the JIT-specific timings reported by EXPLAIN (ANALYZE) add up to anything
> close to the slow-down I'm seeing. Shouldn't compiling and optimization
> time show up there
Hi,
On 2018-07-30 18:01:34 +0200, Pavel Stehule wrote:
> look on
> http://www.postgresql-archive.org/PATCH-LLVM-tuple-deforming-improvements-td6029385.html
> thread, please.
Given the results I just posted in the sibling email I don't think those
issues apply here.
Greetings,
Andres Freund
On Mon, Jul 30, 2018 at 12:01 PM, Pavel Stehule
wrote:
>
>
> 2018-07-30 13:19 GMT+02:00 Jeff Janes :
>
>> On Mon, Jul 30, 2018 at 12:11 AM, Pavel Stehule
>> wrote:
>>
>>> 2018-07-30 1:00 GMT+02:00 Tom Lane :
>>>
David Rowley writes:
> On 29 July 2018 at 17:38, Dinesh Kumar wrote:
>>>
On 2018-07-30 07:19:07 -0400, Jeff Janes wrote:
> On Mon, Jul 30, 2018 at 12:11 AM, Pavel Stehule
> wrote:
>
> > 2018-07-30 1:00 GMT+02:00 Tom Lane :
> >
> >> David Rowley writes:
> >> > On 29 July 2018 at 17:38, Dinesh Kumar wrote:
> >> >> I found performance variance between accessing int1 an
2018-07-30 13:19 GMT+02:00 Jeff Janes :
> On Mon, Jul 30, 2018 at 12:11 AM, Pavel Stehule
> wrote:
>
>> 2018-07-30 1:00 GMT+02:00 Tom Lane :
>>
>>> David Rowley writes:
>>> > On 29 July 2018 at 17:38, Dinesh Kumar wrote:
>>> >> I found performance variance between accessing int1 and int200 colu
On Mon, Jul 30, 2018 at 12:11 AM, Pavel Stehule
wrote:
> 2018-07-30 1:00 GMT+02:00 Tom Lane :
>
>> David Rowley writes:
>> > On 29 July 2018 at 17:38, Dinesh Kumar wrote:
>> >> I found performance variance between accessing int1 and int200 column
>> which
>> >> is quite large.
>>
>> > Have a lo
2018-07-30 1:00 GMT+02:00 Tom Lane :
> David Rowley writes:
> > On 29 July 2018 at 17:38, Dinesh Kumar wrote:
> >> I found performance variance between accessing int1 and int200 column
> which
> >> is quite large.
>
> > Have a look at slot_deform_tuple and heap_deform_tuple. You'll see
> > that
David Rowley writes:
> On 29 July 2018 at 17:38, Dinesh Kumar wrote:
>> I found performance variance between accessing int1 and int200 column which
>> is quite large.
> Have a look at slot_deform_tuple and heap_deform_tuple. You'll see
> that tuples are deformed starting at the first attribute.
On 29 July 2018 at 17:38, Dinesh Kumar wrote:
> I found performance variance between accessing int1 and int200 column which
> is quite large.
Have a look at slot_deform_tuple and heap_deform_tuple. You'll see
that tuples are deformed starting at the first attribute. If you ask
for attribute 200 t
Hello All,
I created a table with 200 bigint column, 200 varchar column. (Postgres
10.4)
create table i200c200 ( pk bigint primary key, int1 bigint, int2
bigint,., int200 bigint, char1 varchar(255),.., char200
varchar(255)) ;
Inserted values only in pk,int1,int200 columns with some rando
17 matches
Mail list logo
