On Thu, Feb 3, 2011 at 07:30, Dan Birken wrote:
> Thank you everybody for the detailed answers, the help is well appreciated.
> A couple of follow-up questions:
> - Is the supercap + flash memory considered superior to the BBU in practice?
I think it's considered about equivalent.
The advantages
On Wed, Feb 2, 2011 at 11:15 PM, Greg Smith wrote:
> Scott Marlowe wrote:
>
> On Wed, Feb 2, 2011 at 10:46 PM, Greg Smith wrote:
>
>
> example. Scott Marlowe was griping recently about a similar issue in some
> of the LSI models, too. I suspect it's a problem impacting several of the
> larger R
Thank you everybody for the detailed answers, the help is well appreciated.
A couple of follow-up questions:
- Is the supercap + flash memory considered superior to the BBU in practice?
Is that type of system well tested?
- Is the linux support of the LSI and Adaptec cards comparable?
-Dan
On W
Mladen Gogala wrote:
The techies at big companies are the guys who will or will not make it
happen. And these guys are not beginners. Appeasing them may actually
go a long way.
The PostgreSQL community isn't real big on appeasing people if it's at
the expense of robustness or correctness, an
Scott Marlowe wrote:
On Wed, Feb 2, 2011 at 10:46 PM, Greg Smith wrote:
example. Scott Marlowe was griping recently about a similar issue in some
of the LSI models, too. I suspect it's a problem impacting several of the
larger RAID cards that use the big Intel IOP processors for their RAID
On Wed, Feb 2, 2011 at 7:00 PM, Craig Ringer
wrote:
> Whatever RAID controller you get, make sure you have a battery backup
> unit (BBU) installed so you can safely enable write-back caching.
> Without that, you might as well use software RAID - it'll generally be
> faster (and cheaper) than HW RA
On Wed, Feb 2, 2011 at 10:46 PM, Greg Smith wrote:
> example. Scott Marlowe was griping recently about a similar issue in some
> of the LSI models, too. I suspect it's a problem impacting several of the
> larger RAID cards that use the big Intel IOP processors for their RAID
> computations, give
Dan Birken wrote:
ADAPTEC 3405 RAID Controller
ADAPTEC 4800 RAID Controller
The 3405 and 4800 are two of Adaptec's older cards with only 128MB of
cache on them. Those are on the slow side compared to the others listed.
LSI MegaRaid 8308 RAID Controller
ADAPTEC 5405 RAID Controller
AD
On Wed, 2011-02-02 at 15:15 -0300, Cesar Arrieta wrote:
> Hi, I have a Server with Fedora Core 11, Tomcat and Postgresql 8.3.
> With Hardware:
> * 8GB RAM
> * 8 processors Intel Xeon E5520 @2.27GHz
> * 250GB SATA DISK
>
> Actually, it serves at most 250 connections.
> The problem happends when it
On 2/2/2011 7:03 PM, Greg Smith wrote:
I think that's not quite the right question. For every person like
yourself who is making an informed "the optimizer is really picking the
wrong index" request, I think there are more who are asking for that but
are not actually right that it will help. I
On Wed, Feb 2, 2011 at 7:03 PM, Greg Smith wrote:
> Given limited resources as a development community, it's hard to justify
> working on hinting--which has its own complexity to do right--when there are
> so many things that I think are more likely to help *everyone* that could be
> done instead.
On 03/02/11 07:15, Dan Birken wrote:
> However, they can't guarantee that any particular RAID controller would
> be in stock when they are building the machine, so basically I would
> like to know if any of these cards are sufficiently better or worse than
> the others that I should either a) wait
Andrew Dunstan wrote:
>
>
> On 02/02/2011 07:17 PM, Greg Smith wrote:
> > I direct anyone who thought Mladen was making a serious comment to
> > http://www.nydailynews.com/news/politics/2009/01/08/2009-01-08_misunderestimate_tops_list_of_notable_bu-3.html
> >
> > if you want to get his little
I direct anyone who thought Mladen was making a serious comment to
http://www.nydailynews.com/news/politics/2009/01/08/2009-01-08_misunderestimate_tops_list_of_notable_bu-3.html
if you want to get his little joke there. I plan to start using
"misunderestimate" more in the future when talking ab
Greg Smith wrote:
> Mladen Gogala wrote:
> > Greg, how many questions about queries not using an index have you
> > seen? There is a reason why people keep asking that. The sheer number
> > of questions like that on this group should tell you that there is a
> > problem there. There must be a re
Mladen Gogala wrote:
Greg, how many questions about queries not using an index have you
seen? There is a reason why people keep asking that. The sheer number
of questions like that on this group should tell you that there is a
problem there. There must be a relatively simple way of influencing
I'm setting up a dedicated linux postgres box with 2x300GB 15k SAS drive in
a RAID 1, though if future load dictates we would like to be able to upgrade
to RAID 10. The hosting provider offers the following options for a RAID
controller (all are the same price):
ADAPTEC 3405 RAID Controller
ADA
On Wed, Feb 2, 2011 at 3:29 PM, Nikolas Everett wrote:
>
>
> On Wed, Feb 2, 2011 at 2:53 PM, Nikolas Everett wrote:
>
>> Given that the a list would be difficult to maintain, is there some way I
>> can make Postgres spit out the list of what locks are taken?
>>
>> --Nik
>>
>
> I just answered my
Justin Pitts wrote:
With all
due respect, I consider myself smarter than the optimizer. I'm 6'4", 235LBS
so telling me that you disagree and that I am more stupid than a computer
program, would not be a smart thing to do. Please, do not misunderestimate
me.
I don't see computer programs
Kenneth Marshall wrote:
I see them come up regularly. However, there really are not all that
many when you consider how many people are using PostgreSQL. Its
optimizer works quite well. Knowing how hints can be misused, I would
rather have the developers use their resource to improve the optimi
On Wed, Feb 2, 2011 at 4:16 PM, Kevin Grittner
wrote:
> Mladen Gogala wrote:
>
>> I'm 6'4", 235LBS so telling me that you disagree and that I am more
>> stupid than a computer program, would not be a smart thing to do.
>
> Even if you had used a smiley there, that would have been incredibly
> ina
Mladen Gogala wrote:
> I'm 6'4", 235LBS so telling me that you disagree and that I am more
> stupid than a computer program, would not be a smart thing to do.
Even if you had used a smiley there, that would have been incredibly
inappropriate. I've never seen a computer program do anything so
On Wed, Feb 02, 2011 at 03:54:26PM -0500, Mladen Gogala wrote:
> Greg Smith wrote:
>> Given that even Oracle kicked out the RBO a long time ago, I'm not so sure
>> longing for those good old days will go very far. I regularly see queries
>> that were tweaked to always use an index run at 1/10 or
Mladen Gogala wrote:
> > 2) The sort of random I/O done by index lookups can be as much as 50X as
> > expensive on standard hard drives as sequential, if every block goes to
> > physical hardware.
> >
>
> Greg, how many questions about queries not using an index have you seen?
> There is a r
Greg Smith wrote:
Given that even Oracle kicked out the RBO a long time ago, I'm not so
sure longing for those good old days will go very far. I regularly see
queries that were tweaked to always use an index run at 1/10 or less the
speed of a sequential scan against the same data. The same pe
On Wed, Feb 2, 2011 at 2:53 PM, Nikolas Everett wrote:
> Given that the a list would be difficult to maintain, is there some way I
> can make Postgres spit out the list of what locks are taken?
>
> --Nik
>
I just answered my own question -
compile with -DLOCK_DEBUG in your src/Makefile.custom an
On Wed, Feb 02, 2011 at 10:06:53AM -0700, Wayne Conrad wrote:
> On 02/01/11 18:30, Greg Smith wrote:
> >>Bonnie++ (-f -n 0 -c 4)
> >>$PGDATA/xlog (RAID1)
> >>random seek: 369/sec
> >>block out: 87 MB/sec
> >>block in: 180 MB/sec
> >>$PGDATA (RAID10, 12 drives)
> >>random seek: 452
> >>block out: 43
Given that the a list would be difficult to maintain, is there some way I
can make Postgres spit out the list of what locks are taken?
--Nik
On Wed, Feb 2, 2011 at 1:58 PM, Greg Smith wrote:
> Nikolas Everett wrote:
>
>> Is there an exhaustive list of what takes what locks and how long they
>>
I mistakenly replied to sender only.
Jon Nelson wrote:
However, sometimes using an index results in a HORRIBLE HORRIBLE plan.
I recently encountered the issue myself, and plopping an ANALYZE
$tablename in there, since I was using a temporary table anyway, make
all the difference. The planner swi
I would personally highly recommend using pgBouncer! I have been using
this in production migrating from MySQL and have had phenomenal success
with it combined with lighttpd and php as an internal information
system. I am getting on average 300 requests per second very low load
average as it is m
Nikolas Everett wrote:
Is there an exhaustive list of what takes what locks and how long they
last? I'm asking because we just had some trouble doing a hot db
change to an 8.3.6 system. I know it is an old version but it is what
I have to work with.
There haven't been any major changes in t
Mladen Gogala wrote:
People are complaining about the optimizer not using the indexes all
over the place, there should be a way to
make the optimizer explicitly prefer the indexes, like was the case
with Oracle's venerable RBO (rules based
optimizer). RBO didn't use statistics, it had a rank of
On Wed, Feb 2, 2011 at 1:19 PM, Jon Nelson wrote:
> However, sometimes using an index results in a HORRIBLE HORRIBLE plan.
> I recently encountered the issue myself, and plopping an ANALYZE
> $tablename in there, since I was using a temporary table anyway, make
> all the difference. The planner sw
On Wed, Feb 02, 2011 at 03:15:22PM -0300, Cesar Arrieta wrote:
> Hi, I have a Server with Fedora Core 11, Tomcat and Postgresql 8.3.
> With Hardware:
> * 8GB RAM
> * 8 processors Intel Xeon E5520 @2.27GHz
> * 250GB SATA DISK
>
> Actually, it serves at most 250 connections.
> The problem happends w
Benjamin Krajmalnik wrote:
So, if I understand correctly, I should strive for a relative increase in
buffers_clean to buffers_backend
Right. Buffers written by a backend are the least efficient way to get
data out of the buffer cache, because the client running into that is
stuck waiting
On Wed, Feb 2, 2011 at 1:11 PM, Mladen Gogala wrote:
> Not necessarily autoanalyze, some default rules for the situations when
> stats is not there should be put in place,
> like the following:
> 1) If there is a usable index on the temp table - use it.
> 2) It there isn't a usable index on the te
On Wed, Feb 2, 2011 at 12:11 PM, Mladen Gogala
wrote:
> Robert Haas wrote:
>>
>> On Tue, Feb 1, 2011 It would be pretty hard to make autoanalyze work on
>> such tables
>> without removing some of the performance benefits of having such
>> tables in the first place - namely, the local buffer manage
Hi, I have a Server with Fedora Core 11, Tomcat and Postgresql 8.3.
With Hardware:
* 8GB RAM
* 8 processors Intel Xeon E5520 @2.27GHz
* 250GB SATA DISK
Actually, it serves at most 250 connections.
The problem happends when it serves many many connections at a time, tables
and queries began to get
Robert Haas wrote:
On Tue, Feb 1, 2011
It would be pretty hard to make autoanalyze work on such tables
without removing some of the performance benefits of having such
tables in the first place - namely, the local buffer manager. But you
could ANALYZE them by hand.
Not necessarily autoanaly
>See how buffers_backend is much larger than buffers_clean, even though
>maxwritten_clean is low? That means the background writer isn't running often
>enough to keep up with cleaning things, even though >it does a lot of work
>when it does kick in. In your situation I'd normally do a first
Cesar Arrieta wrote:
im developing an app that saves information included in
"pg_stat_activity" view in order to monitor querys. The objective of
this app is to gather information about querys that take to long to
finish and overload the server.
I hope you're already setting log_min_duration_
On Tue, Feb 1, 2011 at 6:44 PM, Mladen Gogala wrote:
> On 2/1/2011 6:03 PM, Andrew Dunstan wrote:
>>
>> Whether or not it's bad application design, it's ubiquitous, and we
>> should make it work as best we can, IMNSHO. This often generates
>> complaints about Postgres, and if we really plan for wo
>I was wandering if I could see somehwere the implementation of
>"pg_stat_activity" view
>From psql
\d+ pg_stat_activity
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
www.truviso.com
--
Sent via pgsql-performance mailing list (pgsql-
Greg, It's so nice to get a reply from the author of *the book*. Thank
you for taking the time to help us out.
On 02/01/11 18:30, Greg Smith wrote:
Do you not want any excitement in your life?
I've had database excitement enough to last a lifetime. That's why I'm
mending my ways. Your boo
On Wednesday 02 February 2011 16:21:47 Cesar Arrieta wrote:
Hi,
> If you could help looking about this, or if you know about an app that
> already do this, please let me know.
have a look for http://pgfouine.projects.postgresql.org/
and http://pgfoundry.org/projects/pgstatspack/
HTH,
Jens
--
Hi, im César, im developing an app that saves information included in
"pg_stat_activity" view in order to monitor querys. The objective of this
app is to gather information about querys that take to long to finish and
overload the server. I was wandering if I could see somehwere the
implementation
46 matches
Mail list logo
