On Fri, Oct 2, 2009 at 7:48 PM, Justin Pryzby wrote:
> [I got no response on -general for a few days so I'm trying here]
>
> When we upgraded from linux-2.6.24 to linux-2.6.27, our pg_dump
> duration increased by 20% from 5 hours to 6. My first attempt at
> resolution was to boot with elevator=de
"Sgarbossa Domenico" writes:
> I guess the right query is:
> select distinct on (articolo) articolo,data_ent,prezzo from
> listini_anagrafici order by articolo, data_ent desc
> but it seems that this query runs slowly... about 5/6 seconds.
> I've tried adding this index
> CREATE INDEX articol
Denis Lussier wrote:
> I'm a BSD license fan, but, I don't know much about *BSD otherwise
> (except that many advocates say it runs PG very nicely).
>
> On the Linux side, unless your a dweeb, go with a newer, popular &
> well supported release for Production. IMHO, that's RHEL 5.x or
> CentOS 5.x
The index can produce the sorted output. Add a dummy WHERE clause like
articoli > and data_ent > .
--Imad
On Mon, Sep 28, 2009 at 10:18 PM, Sgarbossa Domenico
wrote:
>
> I need to retrieve the most recent prices per products from a price list
> table:
>
> CREATE TABLE listini_anagrafici
> (
>
[I got no response on -general for a few days so I'm trying here]
When we upgraded from linux-2.6.24 to linux-2.6.27, our pg_dump
duration increased by 20% from 5 hours to 6. My first attempt at
resolution was to boot with elevator=deadline. However that's
actually the default IO scheduler in bo
On Thu, Oct 1, 2009 at 4:46 AM, S Arvind wrote:
>
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??
FreeBSD isn't Linux.
Don't run Fedora, it undergoes way too much Churn.
No real difference between CentOS and RedHat.
I personally prefer openSUSE (or SLES/SLED if you want their
commerical offering).
On Thu, Oct 1, 2009 at 9:43 PM, Benjamin Minshall
wrote:
> Hello all,
>
> I'm looking for your general thoughts on CPU brand and HP disk controllers
> for a PostgreSQL server running Linux. The workload is all over the place
> sometimes OLTP, sometimes huge/long report transactions, sometimes ton
I'm a BSD license fan, but, I don't know much about *BSD otherwise (except
that many advocates say it runs PG very nicely).
On the Linux side, unless your a dweeb, go with a newer, popular & well
supported release for Production. IMHO, that's RHEL 5.x or CentOS 5.x. Of
course the latest SLES & UB
Hi,
I have a pretty small database on my home computer (~25Gb). I have three
250Gb HDDs.
My setup was 1 HDD for OS (Windows XP) and the other 2 HDD in RAID 0 for
postgre database.
Will I see any performance improvement if I instead have 1 HDD for OS, 1 HDD
for pg_xlog and 1HDD for the database?
On Mon, 2009-09-28 at 10:36 -0700, Josh Berkus wrote:
> On 9/26/09 8:19 AM, Greg Smith wrote:
> > This means that the question you want an answer to is "if the OS cache
> > isn't really available, where does giving memory to shared_buffers
> > becomes less efficient than not caching things at all?"
I need to retrieve the most recent prices per products from a price list table:
CREATE TABLE listini_anagrafici
(
id character varying(36) NOT NULL,
articolo character varying(18),
listino character varying(5),
data_ent date,
data_fin date,
prezzo double precision,
ultimo boolean DE
Hi Tom-
Thanks for the response, but I'm not sure what to do with it.
Are you suggesting we might have some transaction (or residue) that's
hanging around and causing this problem?
We do have transactions that run on the order of a couple minutes at
times. In the past, under heavy db loa
Hi all..
please, how can i tune postgres performance?
Thanks.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Sat, Oct 3, 2009 at 2:11 AM, S Arvind wrote:
> Thanks Robert,
> So for our scenario what is the most important factor to be noted
> for performance.
Tough to say without benchmarking, but if you have a lot of small
databases that easily fit in RAM, and a lot of concurrent connections,
14 matches
Mail list logo
