ng for a friend...
-dg
--
David Gould 510 282 0869 da...@sonic.net
If simplicity worked, the world would be overrun with insects.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ment is
knowing that "grouping sets are in" not that "it is July now".
-dg
--
David Gouldda...@sonic.net
If simplicity worked, the world would be overrun with insects.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
would
mainly be the release notes, or some other mark in the sand that says "As of
Alpha-3 feature X is included and expected to mostly work."
-dg
--
David Gould da...@sonic.net
If simplicity worked, the world would be overrun with insects.
--
Sent via pgs
s, tom lane
>
>
I don't have any inside knowledge, but from the presentation given at the
recent SFPUG followed by a bit of google-fu I think these papers are
relevant:
http://www.vldb.org/pvldb/vol4/p539-neumann.pdf
http://sites.computer.org/debull/A14mar/p3.pdf
-dg
--
David Gould
on a
> modern AMD system.
I'll see what I can do. However I don't have acces to any large modern AMD
systems.
-dg
--
David Gould 510 282 0869 da...@sonic.net
If simplicity worked, the world would be overrun with insects.
--
Sent via pgsql-hackers mail
On Tue, 18 Jun 2013 10:09:55 +0300
Heikki Linnakangas wrote:
> On 02.04.2013 22:58, David Gould wrote:
> > I'll give the patch a try, I have a workload that is impacted by spinlocks
> > fairly heavily sometimes and this might help or at least give me more
> > informa
still has a ways to go. Hopefully it is actually there this time.
I'll give the patch a try, I have a workload that is impacted by spinlocks
fairly heavily sometimes and this might help or at least give me more
information. Thanks!
-dg
--
David Gould da...@sonic.
On Fri, 14 Dec 2012 15:39:44 -0500
Robert Haas wrote:
> On Wed, Dec 12, 2012 at 8:29 AM, David Gould wrote:
> > We lose noticable performance when we raise fill-factor above 10. Even 20 is
> > slower.
>
> Whoa.
Any interest in a fill-factor patch to place exactly one row
R) CPU E7-L8867 @ 2.13GHz
stepping : 2
cpu MHz : 2128.478
cache size : 30720 KB
-dg
--
David Gould 510 282 0869 da...@sonic.net
If simplicity worked, the world would be overrun with insects.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
HeapTuple heaptup = heaptuples[ndone + nthispage];
I don't know if this is the same thing. At least in the comments I was
reading trying to figure this out there was some concern that someone
else could change the space on the page. Does RelationGetBufferForTuple()
guara
On Wed, 12 Dec 2012 12:27:11 +0100
Andres Freund wrote:
> On 2012-12-12 03:04:19 -0800, David Gould wrote:
> >
> > COPY IN loops in heap_multi_insert() extending the table until it fills the
> Heh. Nice one. Did you hit that in practice?
Yeah, with a bunch of hosts that
Most of the diff is just indentation changes. Whoever tries this
will
want to test this on a small partition by itself.
-dg
--
David Gould 510 282 0869 da...@sonic.net
If simplicity worked, the world would be overrun with insects.
\set ECHO all
\timing on
drop table if exists
On Tue, 11 Dec 2012 18:58:58 -0700
Josh Kupershmidt wrote:
> On Tue, Dec 11, 2012 at 6:01 PM, David Gould wrote:
> >
> > I'm sure I've had a stroke or something in the middle of the night and just
> > didn't notice, but I'm able to reproduce the follo
med in key does not exist
LINE 2: i INTEGER, PRIMARY KEY (i)
^
Someone please set me straight, and tell me I've had a brain injury because
I am not comfortable with computers just fucking with me which is the other
explanation.
-dg
--
David Gould 510 282 0869
e memory may be so fragmented that this is just a
waste of time.
Real as opposed to transparent hugepages would be a huge win for
applications that try to use high connection counts. Each backend
attached to the postgresql shared memory uses its own set of page table
entries at the rate of 2KB pe
gish systems (128GB to 512GB memory, 32 cores). The system sometimes
goes 99% system time and is very slow and unresponsive to the point of
not successfully completing new tcp connections. Turning off
transparent_hugepages fixes it.
That said, explicit hugepage support for the buffer cache would be a bi
16 matches
Mail list logo
