On Thu, Aug 16, 2012 at 9:02 PM, Bruce Momjian wrote:
> Did we ever make a decision on this patch?
I committed it as 1fc3d18faa8f4476944bc6854be0f7f6adf4aec8.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pg
Did we ever make a decision on this patch?
---
On Sat, Nov 26, 2011 at 09:22:50PM +0530, Pavan Deolasee wrote:
> On some recent benchmarks and profile data, I saw GetSnapshotData
> figures at the very top or near top. For le
On Sat, Nov 26, 2011 at 5:49 PM, Andres Freund wrote:
> On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
>> On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund wrote:
>> > On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
>> >> I'd just as soon keep the fields in a logical order.
On Tue, Nov 29, 2011 at 7:12 AM, Pavan Deolasee
wrote:
> I think that a good idea. We need a representation that needs minimum
> processing to derive the snapshot.
I was looking over the generated code for GetSnapshotData to see if there
is any low hanging fruit for micro-optimization. The assemb
Hi,
On Monday, November 28, 2011 08:55:28 PM Gurjeet Singh wrote:
> This may not be necessary, but can you please share the modified config you
> used for the last run.
I just copied the .conf I had for some independent development.
max_connections = 100
listen_addresses = ''
port=5432
shared_buf
On Tuesday, November 29, 2011 05:51:40 AM Pavan Deolasee wrote:
> On Tue, Nov 29, 2011 at 8:30 AM, Kevin Grittner
>
> wrote:
> > Andres Freund wrote:
> >> I would like to see somebody running a benchmark on a machine with
> >> higher concurrency...
> >
> > Yeah, me too. I don't find it at all
Pavan Deolasee wrote:
> On Sun, Nov 27, 2011 at 12:26 AM, Tom Lane wrote:
> > Pavan Deolasee writes:
> >> On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas
> >> wrote:
> >>> Furthermore, it's
> >>> hard to understand how this could be a net improvement in the general
> >>> case, because now both B
On Sun, Nov 27, 2011 at 12:26 AM, Tom Lane wrote:
> Pavan Deolasee writes:
>> On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas wrote:
>>> Furthermore, it's
>>> hard to understand how this could be a net improvement in the general
>>> case, because now both B and F are copying everything twice (once
On Tue, Nov 29, 2011 at 8:30 AM, Kevin Grittner
wrote:
> Andres Freund wrote:
>
>> I would like to see somebody running a benchmark on a machine with
>> higher concurrency...
>
> Yeah, me too. I don't find it at all hard to believe that we will
> see significant performance benefit by changing t
Andres Freund wrote:
> I would like to see somebody running a benchmark on a machine with
> higher concurrency...
Yeah, me too. I don't find it at all hard to believe that we will
see significant performance benefit by changing the PGPROC structure
so that all parts of it can be accessed thro
Hi Gurjeet,
On Monday, November 28, 2011 08:55:28 PM Gurjeet Singh wrote:
> On Sat, Nov 26, 2011 at 6:51 PM, Andres Freund wrote:
> > On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
> > > On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund
> >
> > wrote:
> > > > On Saturday, November 2
On Sat, Nov 26, 2011 at 6:51 PM, Andres Freund wrote:
> On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
> > On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund
> wrote:
> > > On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> > >> I'd just as soon keep the fields in a logical
Andres Freund wrote:
> All current x86 cpus use 64bytes.
That matches what I found in recent research on the topic.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
> On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund wrote:
> > On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> >> I'd just as soon keep the fields in a logical order.
> >
> > Btw, I don't think the new order is necessarily wo
On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
> On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund wrote:
> > On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> >> I'd just as soon keep the fields in a logical order.
> >
> > Btw, I don't think the new order is necessarily wo
On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund wrote:
> On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
>> I'd just as soon keep the fields in a logical order.
> Btw, I don't think the new order is necessarily worse than the old one.
You forget to attach the benchmark results.
My impr
On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> I'd just as soon keep the fields in a logical order.
Btw, I don't think the new order is necessarily worse than the old one.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> Andres Freund writes:
> > You could also try if it makes a difference reducing SnapshotData to one
> > instead of two cachelines. The data itself fits into one without
> > problems. Trivial patch attached.
> On what grounds do you argue
Andres Freund writes:
> You could also try if it makes a difference reducing SnapshotData to one
> instead of two cachelines. The data itself fits into one without problems.
> Trivial patch attached.
On what grounds do you argue that this patch gets SnapshotData into one
cacheline today (and on
Hi,
On Saturday, November 26, 2011 04:52:50 PM Pavan Deolasee wrote:
> I think now that we have reduced the run time of the function itself,
> we should now try to reduce the number of times the function is
> called. Robert proposed a way to reduce the number of calls per
> transaction. I think we
Pavan Deolasee writes:
> On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas wrote:
>> Furthermore, it's
>> hard to understand how this could be a net improvement in the general
>> case, because now both B and F are copying everything twice (once to
>> the shared area and one to backend-local memory) i
On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas wrote:
> On Sat, Nov 26, 2011 at 10:52 AM, Pavan Deolasee
> wrote:
>> What we can do is when a transaction comes to compute its snapshot, it
>> checks if some other transaction is already computing a snapshot for
>> itself. If so, it just sleeps on th
On Sat, Nov 26, 2011 at 10:52 AM, Pavan Deolasee
wrote:
> What we can do is when a transaction comes to compute its snapshot, it
> checks if some other transaction is already computing a snapshot for
> itself. If so, it just sleeps on the lock. When the other process
> finishes computing the snaps
23 matches
Mail list logo
