There's two papers published recently at Duke that I just found, both of
which use PostgreSQL as part of their research:
Automated SQL Tuning through Trial and (Sometimes) Error:
http://www.cs.duke.edu/~shivnath/papers/dbtest09z.pdf
Tuning Database Configuration Parameters with iTuned:
http:
Michael Stone wrote:
On Wed, Dec 12, 2007 at 12:27:39PM +1200, kelvan wrote:
I have also learnt and also Richard pointed out just not in so many
words the difference in support from a open source community compared
to a non open source company is that the people who give support in
open source
On Wed, Dec 12, 2007 at 12:27:39PM +1200, kelvan wrote:
I have also learnt and also Richard pointed out just not in so many words
the difference in support from a open source community compared to a non
open source company is that the people who give support in open source are
opinionated rathe
On Wed, 12 Dec 2007, kelvan wrote:
my original question is what are the overheads for postgres but obviously no
one knows or no one knows where a webpage containing this information is -_-
In addition to the documentation links people have already suggested, I'd
also suggest
http://andreas.s
Ok thx I have got it thx to David and Scott for the links I now know why I
couldn't find them as I was looking for blocks rather than page damn
synonyms
and to Eric thx for the criticism but yea I failed English so I know my
punctuation is bad unless I concentrate and I am to busy to do that
kelvan wrote:
you know what you lot have left my original question this server is a
temporary piece of shit
my original question is what are the overheads for postgres but obviously no
one knows or no one knows where a webpage containing this information is -_-
overhead information i would t
On Dec 11, 2007, at 5:18 PM, kelvan wrote:
you know what you lot have left my original question this server is a
temporary piece of shit
my original question is what are the overheads for postgres but
obviously no
one knows or no one knows where a webpage containing this
information is -_-
http://www.postgresql.org/docs/8.1/static/storage.html
On Dec 11, 2007 5:18 PM, kelvan <[EMAIL PROTECTED]> wrote:
> you know what you lot have left my original question this server is a
> temporary piece of shit
>
> my original question is what are the overheads for postgres but obviously no
> one
kelvan wrote:
I wonder where did all the punctuation symbols on your keyboard went.
Your email is amazingly hard to read.
> overhead information i would to know is row overheads column overheads and
> header overheads for blocks and anything else i have missed
As for storage overhead, see here:
you know what you lot have left my original question this server is a
temporary piece of shit
my original question is what are the overheads for postgres but obviously no
one knows or no one knows where a webpage containing this information is -_-
overhead information i would to know is row ove
On Tue, 11 Dec 2007, kelvan wrote:
i am going to blow up that mac and burn postgres as i need a more
powerful dbms one that can handle multi threading.
Someone pointed this out already, but I'll repeat: PostgreSQL has a
multi-process architecture that's fully capable of taking advantage of
>>> On Mon, Dec 10, 2007 at 6:15 PM, in message
<[EMAIL PROTECTED]>, Kevin Grittner wrote:
> with 6 MB of RAM
Obviously a typo -- that should read 6 GB of RAM.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
>>> On Mon, Dec 10, 2007 at 6:29 PM, in message <[EMAIL PROTECTED]>,
"kelvan" <[EMAIL PROTECTED]> wrote:
> i need a more powerful dbms one that can
> handle multi threading.
If you're looking to handle a lot of concurrent users, PostgreSQL
has the power. The threading issues really only imp
""Scott Marlowe"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Dec 7, 2007 1:13 PM, kelvan <[EMAIL PROTECTED]> wrote:
>
>> ok heres the thing i dont have a choice i just have to work with whats
>> given
>> whether it is good or not why i need these overheads is for block
>> c
On Dec 7, 2007 1:13 PM, kelvan <[EMAIL PROTECTED]> wrote:
> ok heres the thing i dont have a choice i just have to work with whats given
> whether it is good or not why i need these overheads is for block
> calculations and and tablespace calculations i have to keep everything in a
> very very sma
kelvan wrote:
ok heres the thing i dont have a choice i just have to work with whats given
Ah well, it happens to all of us.
whether it is good or not why i need these overheads is for block
calculations and and tablespace calculations i have to keep everything in a
very very small area on t
"Simon Riggs" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Fri, 2007-12-07 at 12:45 +1200, kelvan wrote:
>
>> hi i need to know all the database overhead sizes and block header sizes
>> etc
>> etc as I have a very complex database to build and it needs to be speed
>> tuned be
On Fri, 2007-12-07 at 12:45 +1200, kelvan wrote:
> hi i need to know all the database overhead sizes and block header sizes etc
> etc as I have a very complex database to build and it needs to be speed
> tuned beyond reckoning
If your need-for-speed is so high, I would suggest using 8.3 or at l
kelvan wrote:
hi i need to know all the database overhead sizes and block header sizes etc
etc as I have a very complex database to build and it needs to be speed
tuned beyond reckoning
[snip]
I am using postgres 8.1 if anyone can post links to pages containing over
head information and inde
hi i need to know all the database overhead sizes and block header sizes etc
etc as I have a very complex database to build and it needs to be speed
tuned beyond reckoning
I have gathered some relevant information form the documentation such as all
the data type sizes and the RM block informa
20 matches
Mail list logo
