Bruce,
> Someone should ask them to remove the article.
"Someone".
Um, *who* taught for Big Nerd Ranch for several years, Bruce?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, ple
Mark,
This fits the typical pattern of the "Big Honking Datamart" for clickstream
analysis, a usage pattern that stresses the capability of all DBMS. Large
companies spend $1M + on combinations of SW and HW to solve this problem,
and only the large scale parallel DBMS can handle the load. Player
posting this here instead of the GENERAL list...richard is right, this is more
of a performance question than a general question.
thanks,
Mark Jensen
- Forwarded Message
From: Mark Jensen <[EMAIL PROTECTED]>
To: Richard Huxton
Cc: pgsql-general@po
Brian Hurt wrote:
> Ron Mayer wrote:
>> Brian Hurt wrote:
>>> Mark Lewis wrote:
On Wed, 2006-11-29 at 08:25 -0500, Brian Hurt wrote:
> But, especially given priority inheritance, is there any
>
> That second paper is interesting in that it says that STM solves the
> priority inversi
Hi List;
I have a client looking to host/co-locate multiple PostgreSQL clusters
(inclusive of PL/pgSQL application code) per server. I did some co-location
work several years back with one of the bigger telco's and remember there
were dire consequences for not carefully evaluating the expected
Ron Mayer wrote:
Brian Hurt wrote:
Mark Lewis wrote:
On Wed, 2006-11-29 at 08:25 -0500, Brian Hurt wrote:
I have the same question. I've done some embedded real-time
programming, so my innate reaction to priority inversions is that
they're evil. But, especially given prior
Brian Hurt wrote:
> Mark Lewis wrote:
>> On Wed, 2006-11-29 at 08:25 -0500, Brian Hurt wrote:
>>
>>> I have the same question. I've done some embedded real-time
>>> programming, so my innate reaction to priority inversions is that
>>> they're evil. But, especially given priority inheritance,
Alessandro Baretta <[EMAIL PROTECTED]> writes:
> I am considering the possibility of rebuilding the server with
> NAMEDATALEN equal to 256. I have seen an interesting thread [1] about
> the performance impact of raising NAMEDATALEN, but it did not seem
> conclusive.
More to the point, tests done o
Mark Lewis wrote:
On Wed, 2006-11-29 at 08:25 -0500, Brian Hurt wrote:
...
I have the same question. I've done some embedded real-time
programming, so my innate reaction to priority inversions is that
they're evil. But, especially given priority inheritance, is there any
situation where
On Wed, 2006-11-29 at 08:25 -0500, Brian Hurt wrote:
...
> I have the same question. I've done some embedded real-time
> programming, so my innate reaction to priority inversions is that
> they're evil. But, especially given priority inheritance, is there any
> situation where priority inversi
Ron Mayer wrote:
Before asking them to remove it, are we sure priority inversion
is really a problem?
I thought this paper: http://www.cs.cmu.edu/~bianca/icde04.pdf
did a pretty good job at studying priority inversion on RDBMs's
including PostgreSQL on various workloads (TCP-W and TCP-C) and
fo
Gentlemen,
I use a modeling language which compiles down to a fairly verbose SQL DDL. If I
use semantically transparent identifiers in the modeling language, the compiler
easily generates identifiers much longer than the default value of NAMEDATALEN.
I am considering the possibility of rebuildin
Mark Kirkwood wrote:
> Ron Mayer wrote:
>> Short summary:
>> * Papers studying priority inversion issues with
>> databases including PosgreSQL and realistic workloads
>> conclude setpriority() helps even in the presence of
>> priority inversion issues for TCP-C and TCP-W like
>> w
13 matches
Mail list logo
