On Sat, Jan 7, 2017 at 11:27 AM, Mithun Cy wrote:
> On Thu, Jan 5, 2017 at 6:15 PM, Amit Kapila wrote:
>>
>> Your test and results look good, what kind of m/c you have used to
>> test this. Let me see if I or one of my colleague can do this
On Sat, Jan 7, 2017 at 11:27 AM, Mithun Cy wrote:
Sorry Auto plain text setting has disturbed the table indentation.
Attaching the spreadsheet for same.
--
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com
On Thu, Jan 5, 2017 at 6:15 PM, Amit Kapila wrote:
>
> Your test and results look good, what kind of m/c you have used to
> test this. Let me see if I or one of my colleague can do this and
> similar test on some high-end m/c.
As discussed with Amit, I have tried to run
On Thu, Jan 5, 2017 at 6:15 PM, Amit Kapila wrote:
>
> Your test and results look good, what kind of m/c you have used to
> test this.
I ran it on my Macbook Pro, so nothing fancy. The code was compiled with
simple ./confgure and with no special flags. The only
On Wed, Jan 4, 2017 at 11:45 PM, Pavan Deolasee
wrote:
>
>
> On Tue, Jan 3, 2017 at 9:33 PM, Robert Haas wrote:
>>
>> On Mon, Jan 2, 2017 at 1:36 AM, Amit Kapila
>> wrote:
>> > Okay, but I think if we know how much is the
Pavan Deolasee wrote:
> A transaction then updates the second column in the table. So the
> refactored patch will do heap_getattr() on more columns that the master
> while checking if HOT update is possible and before giving up.
Thanks.
> 1-client
> Master
On Tue, Jan 3, 2017 at 9:33 PM, Robert Haas wrote:
>
> On Mon, Jan 2, 2017 at 1:36 AM, Amit Kapila
wrote:
> > Okay, but I think if we know how much is the additional cost in
> > average and worst case, then we can take a better call.
>
> Yeah. We
On Mon, Jan 2, 2017 at 1:36 AM, Amit Kapila wrote:
> Okay, but I think if we know how much is the additional cost in
> average and worst case, then we can take a better call.
Yeah. We shouldn't just rip out optimizations that are inconvenient
without doing some test of
On Mon, Jan 2, 2017 at 10:59 AM, Pavan Deolasee
wrote:
>
> On Mon, Jan 2, 2017 at 10:17 AM, Amit Kapila
> wrote:
>>
>> On Mon, Jan 2, 2017 at 9:28 AM, Pavan Deolasee
>> wrote:
>> >
>> >
>> > On Mon, Jan 2, 2017 at 8:52
On Mon, Jan 2, 2017 at 10:17 AM, Amit Kapila
wrote:
> On Mon, Jan 2, 2017 at 9:28 AM, Pavan Deolasee
> wrote:
> >
> >
> > On Mon, Jan 2, 2017 at 8:52 AM, Amit Kapila
> wrote:
> >>
> >>
> >> I think there is some chance
On Mon, Jan 2, 2017 at 9:28 AM, Pavan Deolasee wrote:
>
>
> On Mon, Jan 2, 2017 at 8:52 AM, Amit Kapila wrote:
>>
>>
>> I think there is some chance that such a change could induce
>> regression for the cases when there are many index columns or
On Mon, Jan 2, 2017 at 8:52 AM, Amit Kapila wrote:
>
> I think there is some chance that such a change could induce
> regression for the cases when there are many index columns or I think
> even when index is on multiple columns (consider index is on first and
> eight
On Thu, Dec 29, 2016 at 4:50 AM, Alvaro Herrera
wrote:
> Pursuant to my comments at
> https://www.postgresql.org/message-id/20161223192245.hx4rbrxbrwtgwj6i@alvherre.pgsql
> and because of a stupid bug I found in my indirect indexes patch, I
> rewrote (read: removed)
Here's a version with fixed comments.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index ea579a0..19edbdf 100644
---
14 matches
Mail list logo