On Jun 16, 2010, at 1:53 PM, Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of lun jun 14 23:57:11 -0400 2010:
>> Scott Carey writes:
>>> Great points. There is one other option that is decent for the WAL:
>>> If splitting out a volume is not acceptable for the OS and WAL --
>>> abso
On 6/18/10 2:15 AM, Matthew Wakeling wrote:
> I'd like to point out the costs involved in having a whole separate
> "version" of Postgres that has all this safety switched off. Package
> managers will not thank anyone for having to distribute another version
> of the system, and woe betide the user
> It must be a setting, not a version.
>
> For instance suppose you have a session table for your website and a
> users table.
>
> - Having ACID on the users table is of course a must ;
> - for the sessions table you can drop the "D"
You're trying to solve a different use-case than the one I am
Kevin Grittner wrote:
Yeb Havinga wrote:
concerning gist indexes:
1) with larger block sizes and hence, larger # entries per gist
page, results in more generic keys of those pages. This in turn
results in a greater number of hits, when the index is queried, so
a larger part of the index i
Greg Smith writes:
> Your characterization of the potential speed up here is "Using a proper tree
> inside the index page would improve the CPU usage of the index lookups",
> which seems quite reasonable. Regardless, when I consider "is that
> something I have any reason to suspect is a bottle
Yeb Havinga wrote:
> concerning gist indexes:
>
> 1) with larger block sizes and hence, larger # entries per gist
> page, results in more generic keys of those pages. This in turn
> results in a greater number of hits, when the index is queried, so
> a larger part of the index is scanned. NB th
Greg Smith wrote:
Matthew Wakeling wrote:
This sort of thing has been fairly well researched at an academic
level, but has not been implemented in that many real world
situations. I would encourage its use in Postgres.
I guess, but don't forget that work on PostgreSQL is driven by what
probl
Kenneth Marshall wrote:
Zabbix-1.8+ is also worth taking a look at and it can run off our
favorite database. It allows for some very flexible monitoring and
trending data collection.
Note that while Zabbix is perfectly reasonable general solution, the
number of things it monitors out of the
"Jatinder Sangha" wrote:
> I have a simple query that when planned either uses hash-
> aggregates or a sort depending on the amount of working memory
> available. The problem is that when it uses the hash-aggregates,
> the query runs 25% slower than when using the sort method.
>
> The table in
Matthew Wakeling wrote:
This sort of thing has been fairly well researched at an academic
level, but has not been implemented in that many real world
situations. I would encourage its use in Postgres.
I guess, but don't forget that work on PostgreSQL is driven by what
problems people are actu
On Fri, 18 Jun 2010, Robert Haas wrote:
On Tue, Jun 15, 2010 at 8:23 AM, Matthew Wakeling wrote:
Absolutely, and I said in
http://archives.postgresql.org/pgsql-performance/2010-03/msg00272.php
but applied to the Postgres B-tree indexes instead of heaps.
This is an interesting idea. I would g
Hi,
I've noticed something that I find strange with the hash-aggregate feature of
Postgres. I'm currently running Postgres v8.4.1 on Debian Linux 64-bit.
I have a simple query that when planned either uses hash-aggregates or a sort
depending on the amount of working memory available. The probl
On Fri, Jun 18, 2010 at 12:46:11AM +0100, Tom Wilcox wrote:
> On 17/06/2010 22:41, Greg Smith wrote:
>> Tom Wilcox wrote:
>>> Any suggestions for good monitoring software for linux?
>>
>> By monitoring, do you mean for alerting purposes or for graphing purposes?
>> Nagios is the only reasonable c
I'd like to point out the costs involved in having a whole separate
"version"
It must be a setting, not a version.
For instance suppose you have a session table for your website and a users
table.
- Having ACID on the users table is of course a must ;
- for the sessions table you can dro
On Tue, Jun 15, 2010 at 8:23 AM, Matthew Wakeling wrote:
> Absolutely, and I said in
> http://archives.postgresql.org/pgsql-performance/2010-03/msg00272.php
> but applied to the Postgres B-tree indexes instead of heaps.
This is an interesting idea. I would guess that you could simulate
this to s
Dimitri Fontaine wrote:
Well I guess I'd prefer a per-transaction setting
Not possible, as many others have said. As soon as you make an unsafe
transaction, all the other transactions have nothing to rely on.
On Thu, 17 Jun 2010, Pierre C wrote:
A per-table (or per-index) setting makes more
16 matches
Mail list logo
