Greg Smith wrote:
> I'm not sure exactly what is useful to be learned from that
> specific work. But it does suggest two things: one, this is far
> from an easy thing to fix. Two, the only reason MySQL does so
> well on it is because there was some focused work on it, taking a
> quite a while
I did some more research into the memory allocation hotspots found in
the profile, in regards to what MySQL has done in those areas. (And by
"research" I mean "went to the bar last night and asked Baron about
it") The issue of memory allocation being a limiter on performance has
been nagging
Joshua Berkus writes:
> Certainly any sacrifice of functionality in order to be faster at that kind
> of trivial workload would be foolhardy.
Yeah, and I'd further say that any sacrifice of maintainability would be
equally foolhardy. In particular I'm repelled by David's proposal of a
whole par
On 04/15/2011 09:59 AM, Joshua Berkus wrote:
All,
While it would be nice to improve our performance on this workload, let me
point out that it's not a very important workload from the point of view of
real performance challenges. Yes, there are folks out there with 100MB
databases who only r
All,
While it would be nice to improve our performance on this workload, let me
point out that it's not a very important workload from the point of view of
real performance challenges. Yes, there are folks out there with 100MB
databases who only run one-liner select queries. But frankly,
Val
Noah Misch writes:
> On Thu, Apr 14, 2011 at 05:10:41PM -0400, Tom Lane wrote:
>> FWIW, mysql used to use gperf for this purpose, but they've abandoned it
>> in favor of some homegrown hashing scheme.
> Do you have any details, like when mysql did this? With a quick look, I'm
> failing to find c
On Thu, Apr 14, 2011 at 11:16:03PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Apr 14, 2011 at 10:43:16AM -0400, Tom Lane wrote:
> >> ... I think a lot of this ultimately traces to the extensible,
> >> data-type-agnostic design philosophy. The fact that we don't
> >> know what an in
On Thu, Apr 14, 2011 at 05:10:41PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Apr 14, 2011 at 11:15:00AM -0700, Robert Haas wrote:
> >> It shouldn't be
> >> terribly difficult to come up with some kind of hash function based
> >> on, say, the first two characters of the keyword that w
On 14.04.2011 23:02, Tom Lane wrote:
Heikki Linnakangas writes:
There's one very low-hanging fruit here, though. I profiled the pgbench
case, with -M prepared, and found that like in Greg Smith's profile,
hash_seq_search pops up quite high in the list. Those calls are coming
from LockReleaseAll
David Fetter writes:
> On Thu, Apr 14, 2011 at 10:43:16AM -0400, Tom Lane wrote:
>> ... I think a lot of this ultimately
>> traces to the extensible, data-type-agnostic design philosophy. The
>> fact that we don't know what an integer is until we look in pg_type,
>> and don't know what an "=" ope
On Thursday 14 April 2011 23:10:41 Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Apr 14, 2011 at 11:15:00AM -0700, Robert Haas wrote:
> >> It shouldn't be
> >> terribly difficult to come up with some kind of hash function based
> >> on, say, the first two characters of the keyword that would be
On Thu, Apr 14, 2011 at 4:10 PM, Tom Lane wrote:
> Noah Misch writes:
>> On Thu, Apr 14, 2011 at 11:15:00AM -0700, Robert Haas wrote:
>>> It shouldn't be
>>> terribly difficult to come up with some kind of hash function based
>>> on, say, the first two characters of the keyword that would be a lo
Noah Misch writes:
> On Thu, Apr 14, 2011 at 11:15:00AM -0700, Robert Haas wrote:
>> It shouldn't be
>> terribly difficult to come up with some kind of hash function based
>> on, say, the first two characters of the keyword that would be a lot
>> faster than what we're doing now.
> I'd look at `g
On Thu, Apr 14, 2011 at 12:45 PM, Noah Misch wrote:
>> It shouldn't be
>> terribly difficult to come up with some kind of hash function based
>> on, say, the first two characters of the keyword that would be a lot
>> faster than what we're doing now.
>
> I'd look at `gperf', which generates code f
Andres Freund writes:
> Where I am with you is that its quite possible that it will not make sense
> (performancewise) for all contexts. Which is quite annoying.
The mcxt stuff was designed from day one to support multiple types of
contexts, so it wouldn't be very hard at all to have different c
On Thursday 14 April 2011 22:21:26 Alvaro Herrera wrote:
> Excerpts from Andres Freund's message of jue abr 14 17:08:34 -0300 2011:
> > Hi,
> >
> > On Thursday 14 April 2011 16:43:16 Tom Lane wrote:
> > > I doubt that it's possible to make AllocSetAlloc radically cheaper.
> >
> > I actually doubt
On Thu, Apr 14, 2011 at 2:08 AM, Greg Smith wrote:
> This week several list regulars here waded into the MySQL Convention. I
> decided to revisit PostgreSQL vs. MySQL performance using the sysbench
> program as part of that. It's not important to what I'm going to describe
> to understand exactl
Heikki Linnakangas wrote:
In this case you could just use prepared statements and get rid of all
the parser related overhead, which includes much of the allocations.
Trying that gives me around 9200 TPS instead of 5500 on my laptop, so a
pretty big gain here. Will have to include that in my n
Excerpts from Andres Freund's message of jue abr 14 17:08:34 -0300 2011:
> Hi,
>
> On Thursday 14 April 2011 16:43:16 Tom Lane wrote:
> > I doubt that it's possible to make AllocSetAlloc radically cheaper.
> I actually doubt your doubt. I think you could add some SLAB like interface
> for common
Hi,
On Thursday 14 April 2011 16:43:16 Tom Lane wrote:
> I doubt that it's possible to make AllocSetAlloc radically cheaper.
I actually doubt your doubt. I think you could add some SLAB like interface
for common allocation sizes making it significantly faster for some uses
(because allocation/de
Heikki Linnakangas writes:
> There's one very low-hanging fruit here, though. I profiled the pgbench
> case, with -M prepared, and found that like in Greg Smith's profile,
> hash_seq_search pops up quite high in the list. Those calls are coming
> from LockReleaseAll(), where we scan the local l
On Thu, Apr 14, 2011 at 11:15:00AM -0700, Robert Haas wrote:
> It's fairly far down in the noise on this particular profile, but in
> the low-hanging fruit department, I think we should fix
> ScanKeywordLookup to use a smarter algorithm that is more like O(1)
> rather than O(lg n) in the number of
On 14.04.2011 17:43, Tom Lane wrote:
Greg Smith writes:
samples %image name symbol name
53548 6.7609 postgres AllocSetAlloc
32787 4.1396 postgres MemoryContextAllocZeroAligned
26330 3.3244 postgres base_yypars
On Thu, Apr 14, 2011 at 7:43 AM, Tom Lane wrote:
> I doubt that it's possible to make AllocSetAlloc radically cheaper.
> I think the more likely route to improvement there is going to be to
> find a way to do fewer pallocs. For instance, if we had more rigorous
> rules about which data structures
On Thu, Apr 14, 2011 at 10:43:16AM -0400, Tom Lane wrote:
>
> I doubt that it's possible to make AllocSetAlloc radically cheaper.
> I think the more likely route to improvement there is going to be to
> find a way to do fewer pallocs. For instance, if we had more rigorous
> rules about which data
Greg Smith writes:
> samples %image name symbol name
> 53548 6.7609 postgres AllocSetAlloc
> 32787 4.1396 postgres MemoryContextAllocZeroAligned
> 26330 3.3244 postgres base_yyparse
> 21723 2.7427 postgres
This week several list regulars here waded into the MySQL Convention. I
decided to revisit PostgreSQL vs. MySQL performance using the sysbench
program as part of that. It's not important to what I'm going to
describe to understand exactly what statements sysbench runs here or how
to use it, b
27 matches
Mail list logo
