Re: [PERFORM] Dataset is fetched from cache but still takes same time to fetch records as first run

>From: Tom Lane >To: Sumeet Shukla >Cc: Dave Stibrany ; pgsql-performance@postgresql.org >Sent: Friday, 23 June 2017, 5:50 >Subject: Re: [PERFORM] Dataset is fetched from cache but still takes same time >to fetch records as

Re: [PERFORM] Hi

> From: Daulat Ram > To: "pgsql-performance@postgresql.org" > Sent: Thursday, 13 April 2017, 7:25 > Subject: [PERFORM] Hi > > Hello, > > I need to know the criteria behind for settings the work_mem in PostgreSQL, > please give the

Re: [PERFORM] Clarification on using pg_upgrade

- Original Message - > From: Tory M Blue > To: Jim Nasby > Cc: "pgsql-performance@postgresql.org" > Sent: Tuesday, 14 June 2016, 22:08 > Subject: Re: [PERFORM] Clarification on using pg_upgrade > > Right,

Re: [PERFORM] slony rpm help slony1-95-2.2.2-1.rhel6.x86_64

> From: avi Singh >To: pgsql-performance@postgresql.org >Sent: Saturday, 4 June 2016, 0:03 >Subject: [PERFORM] slony rpm help slony1-95-2.2.2-1.rhel6.x86_64 > > > >Hi All > Can anyone please point me to location from where i can get slony >

Re: [PERFORM] Index scan cost calculation

> From: Jim Nasby <jim.na...@bluetreble.com> >To: Jeff Janes <jeff.ja...@gmail.com>; Glyn Astill <glynast...@yahoo.co.uk> >Cc: Pgsql-performance <pgsql-performance@postgresql.org> >Sent: Wednesday, 2 December 2015, 22:32 >Subject: Re: [PERFORM] Index scan

Re: [PERFORM] Index scan cost calculation

> >Clauses that can't be used in an "indexable" way are excluded from the >index selectivity, but not from the total query selectivity. > >> Or is it just likely that the selection of the new index is just by chance? > >Bingo. > Got it, thanks! Very much appreciated. Glyn -- Sent via

Re: [PERFORM] Index scan cost calculation

> From: Jeff Janes <jeff.ja...@gmail.com> > To: Glyn Astill <glynast...@yahoo.co.uk> > Cc: Pgsql-performance <pgsql-performance@postgresql.org> > Sent: Saturday, 28 November 2015, 19:25 > Subject: Re: [PERFORM] Index scan cost calculation > > &

[PERFORM] Index scan cost calculation

Hi All, Using pg 9.4.5 I'm looking at a table set up by a 3rd party application and trying to figure out why a particular index is being chosen over another for updates/deletes. >From what I can see the reason is that plans using either index have the same >exactly the same cost. So rather

Re: [PERFORM] Index scan cost calculation

- Original Message - > From: Glyn Astill <glynast...@yahoo.co.uk> > To: Pgsql-performance <pgsql-performance@postgresql.org> > Sent: Thursday, 26 November 2015, 16:11 > Subject: [PERFORM] Index scan cost calculation > > Hi All, > > Using pg 9.4.5 I'

Re: [PERFORM] Index scan cost calculation

- Original Message - > From: Tom Lane <t...@sss.pgh.pa.us> > To: Glyn Astill <glynast...@yahoo.co.uk> > Cc: Pgsql-performance <pgsql-performance@postgresql.org> > Sent: Thursday, 26 November 2015, 16:44 > Subject: Re: [PERFORM] Index scan cost calc

Re: [PERFORM] shared_buffers vs Linux file cache

From: Huan Ruan huan.ruan...@gmail.com To: pgsql-performance@postgresql.org Sent: Thursday, 15 January 2015, 11:30 Subject: [PERFORM] shared_buffers vs Linux file cache Hi All I thought 'shared_buffers' sets how much memory that is dedicated to PostgreSQL to use for caching data,

Re: [PERFORM] 9.0 performance degradation with kernel 3.11

From: Filip Rembiałkowski filip.rembialkow...@gmail.com To: pgsql-performance@postgresql.org Sent: Thursday, 13 November 2014, 8:10 Subject: [PERFORM] 9.0 performance degradation with kernel 3.11 Hi After upgrading our 9.0 database server from: openSUSE 11.4, kernel 2.6.37.6-24-default, Pg

Re: [PERFORM] High CPU usage / load average after upgrading to Ubuntu 12.04

From: Josh Berkus j...@agliodbs.com To: Scott Marlowe scott.marl...@gmail.com Cc: pgsql-performance@postgresql.org Sent: Thursday, 21 February 2013, 3:14 Subject: Re: [PERFORM] High CPU usage / load average after upgrading to Ubuntu 12.04 Sounds to me like your IO system is stalling on

Re: [PERFORM] hardware advice

- Original Message - From: David Boreham david_l...@boreham.org To: pgsql-performance@postgresql.org pgsql-performance@postgresql.org Cc: Sent: Tuesday, 2 October 2012, 16:14 Subject: Re: [PERFORM] hardware advice On 10/2/2012 2:20 AM, Glyn Astill wrote: newer R910s recently

Re: [PERFORM] hardware advice

From: M. D. li...@turnkey.bz To: pgsql-performance@postgresql.org Sent: Friday, 28 September 2012, 18:33 Subject: Re: [PERFORM] hardware advice On 09/28/2012 09:57 AM, David Boreham wrote: On 9/28/2012 9:46 AM, Craig James wrote: Your best warranty would be

Re: [PERFORM] H800 + md1200 Performance problem

From: Scott Marlowe scott.marl...@gmail.com On Mon, Apr 16, 2012 at 8:13 AM, Cesar Martin cmart...@gmail.com wrote: Hi, Finally the problem was BIOS configuration. DBPM had was set to Active Power Controller I changed this to Max Performance. 

Re: [PERFORM] H800 + md1200 Performance problem

From: Tomas Vondra t...@fuzzy.cz But the fluctuation, that surely is strange. What are the page cache dirty limits, i.e. cat /proc/sys/vm/dirty_background_ratio cat /proc/sys/vm/dirty_ratio That's probably #1 source I've seen responsible for such issues (on machines with a lot of RAM).

Re: [PERFORM] Very long deletion time on a 200 GB database

Do you have any more detailed information about the hardware, what sort of disk configuration does it have? Can you get onto the machine to look at what is using those resources?  You mention the 25gb of virtual memory; is that being used?  If so is it being used by postgres or something else? 

Re: [PERFORM] Linux: more cores = less concurrency.

--- On Tue, 12/4/11, Greg Smith g...@2ndquadrant.com wrote: From: Greg Smith g...@2ndquadrant.com Subject: Re: [PERFORM] Linux: more cores = less concurrency. To: Kevin Grittner kevin.gritt...@wicourts.gov Cc: da...@lang.hm, Steve Clark scl...@netwolves.com, Glyn Astill glynast

Re: [PERFORM] Linux: more cores = less concurrency.

--- On Tue, 12/4/11, Merlin Moncure mmonc...@gmail.com wrote: The issue I'm seeing is that 8 real cores outperform 16 real cores, which outperform 32 real cores under high concurrency. With every benchmark I've done of PostgreSQL, the knee in the performance graph comes right around

Re: [PERFORM] Linux: more cores = less concurrency.

--- On Tue, 12/4/11, Scott Marlowe scott.marl...@gmail.com wrote: From: Scott Marlowe scott.marl...@gmail.com Subject: Re: [PERFORM] Linux: more cores = less concurrency. To: Glyn Astill glynast...@yahoo.co.uk Cc: pgsql-performance@postgresql.org Date: Tuesday, 12 April, 2011, 6:55 On Mon

Re: [PERFORM] Linux: more cores = less concurrency.

--- On Mon, 11/4/11, Kevin Grittner kevin.gritt...@wicourts.gov wrote: From: Kevin Grittner kevin.gritt...@wicourts.gov Subject: Re: [PERFORM] Linux: more cores = less concurrency. To: da...@lang.hm, Steve Clark scl...@netwolves.com, Kevin Grittner kevin.gritt...@wicourts.gov, Glyn Astill

Re: [PERFORM] Linux: more cores = less concurrency.

--- On Tue, 12/4/11, Merlin Moncure mmonc...@gmail.com wrote: Can we see some iobound and cpubound pgbench runs on both servers? Of course, I'll post when I've gotten to that. Ok, there's no writing going on -- so the i/o tets aren't necessary. Context switches are also not too

Re: [PERFORM] Linux: more cores = less concurrency.

--- On Tue, 12/4/11, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Wow, zero idle and zero wait, and single digit for system.  Did you ever run those RAM speed tests?  (I don't remember seeing results for that -- or failed to recognize them.)  At this point, my best guess at this point

[PERFORM] Linux: more cores = less concurrency.

Hi Guys, I'm just doing some tests on a new server running one of our heavy select functions (the select part of a plpgsql function to allocate seats) concurrently.  We do use connection pooling and split out some selects to slony slaves, but the tests here are primeraly to test what an

Re: [PERFORM] Linux: more cores = less concurrency.

--- On Mon, 11/4/11, Joshua D. Drake j...@commandprompt.com wrote: From: Joshua D. Drake j...@commandprompt.com Subject: Re: [PERFORM] Linux: more cores = less concurrency. To: Kevin Grittner kevin.gritt...@wicourts.gov Cc: pgsql-performance@postgresql.org, Glyn Astill glynast

Re: [PERFORM] Linux: more cores = less concurrency.

--- On Mon, 11/4/11, Scott Marlowe scott.marl...@gmail.com wrote: Just FYI, in synthetic pgbench type benchmarks, a 48 core AMD Magny Cours with LSI HW RAID and 34 15k6 Hard drives scales almost linearly up to 48 or so threads, getting into the 7000+ tps range.  With SW RAID it gets into

Re: [PERFORM] Linux: more cores = less concurrency.

kevin.gritt...@wicourts.gov, pgsql-performance@postgresql.org, Glyn Astill glynast...@yahoo.co.uk Date: Monday, 11 April, 2011, 21:04 On Mon, 11 Apr 2011, Steve Clark wrote: the limit isn't 8 cores, it's that the hyperthreaded cores don't work well with the postgres access patterns. This has

Re: [PERFORM] Linux: more cores = less concurrency.

--- On Mon, 11/4/11, Scott Marlowe scott.marl...@gmail.com wrote: From: Scott Marlowe scott.marl...@gmail.com Subject: Re: [PERFORM] Linux: more cores = less concurrency. To: Glyn Astill glynast...@yahoo.co.uk Cc: Kevin Grittner kevin.gritt...@wicourts.gov, Joshua D. Drake j

[PERFORM] Linux I/O schedulers - CFQ random seeks

Hi Guys, I'm in the process of setting up some new hardware and am just doing some basic disk performance testing with bonnie++ to start with. I'm seeing a massive difference on the random seeks test, with CFQ not performing very well as far as I can see. The thing is I didn't see this sort

Re: [PERFORM] Which RAID Controllers to pick/avoid?

--- On Thu, 3/2/11, Greg Smith g...@2ndquadrant.com wrote: The 5405 and 5805 models do have a known problem where they overheat if you don't have enough cooling in the server box, with the 5805 seeming to be the bigger source of such issues.  See the reviews at

Re: [PERFORM] SATA drives performance

--- On Fri, 25/12/09, Scott Marlowe scott.marl...@gmail.com wrote: It does kind of knock the stuffing out of the argument that buying from the big vendors ensures good hardware experiences.  I've had similar problems from all the big vendors in the past.  I can't imagine getting treated

Re: [PERFORM] RAID card recommendation

--- On Tue, 24/11/09, Scott Marlowe scott.marl...@gmail.com wrote: Jochen Erwied joc...@pgsql-performance.erwied.eu wrote: Since I'm currently looking at upgrading my own database server, maybe some of the experts can give a comment on one of the following controllers: - Promise

[PERFORM] Adaptec Zero-Maintenance Cache Protection - Anyone using?

Hi Chaps, I'm putting together some new servers, and whilst I've been happy with our current config of Adaptec 5805's with bbu I've noticed these 5805Z cards, apparently the contents of DRAM is copied into onboard flash upon power failure. Just wondered if anyone had any experience of this

[PERFORM] [OT] Recommended whitebox server vendors in the UK?

Hi chaps, Can anyone recommend a decent server vendor in the UK? I'm looking to deploy a new machine to handle some of our non-critical data, and I'm just wondering if I can avoid the pains I've had with dell hardware recently. Also whilst I'm asking, does anyone else find their dell BMC/DRAC

Re: [PERFORM] Used computers?

Here in the UK, we have Waste electrical and electronic equipment (WEEE) companies that'll safely destroy or sell them on for a cut of the profits. --- On Mon, 20/7/09, Craig James craig_ja...@emolecules.com wrote: From: Craig James craig_ja...@emolecules.com Subject: [PERFORM] Used

Re: [PERFORM] running bonnie++

You should be able to get a good idea of the options from man bonnie++. I've always just used the defaults with bonnie++ Also, you'll find Gregs older notes are here http://www.westnet.com/~gsmith/content/postgresql/pg-disktesting.htm --- On Wed, 27/5/09, Alan McKay alan.mc...@gmail.com

Re: [PERFORM] 2.6.26 kernel and PostgreSQL

--- On Mon, 13/4/09, Greg Smith gsm...@gregsmith.com wrote: From: Greg Smith gsm...@gregsmith.com Subject: Re: [PERFORM] 2.6.26 kernel and PostgreSQL To: Glyn Astill glynast...@yahoo.co.uk Cc: pgsql-performance@postgresql.org, Kevin Grittner kevin.gritt...@wicourts.gov Date: Monday, 13

[PERFORM] 2.6.26 kernel and PostgreSQL

Hi chaps, Is anyone using 2.6.26 with postgres? I was thinking about shifting my home test machine up from 2.6.18, however I recall reading a post somewhere a while back about the scheduler in more recent versions being a bit cranky... I just thought I'd ask before I go ahead, I don't have

Re: [PERFORM] 2.6.26 kernel and PostgreSQL

--- On Fri, 10/4/09, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Glyn Astill glynast...@yahoo.co.uk wrote: I was thinking about shifting my home test machine up from 2.6.18, however I recall reading a post somewhere a while back about the scheduler in more recent versions

Re: [PERFORM] Prepared statement does not exist

--- On Fri, 20/3/09, Nimesh Satam nimesh.z...@gmail.com wrote: From: Nimesh Satam nimesh.z...@gmail.com We are receving the following error in the postgres database logs: 2009-03-19 02:14:20 PDT [2547]: [79-1] LOG: duration: 0.039 ms statement: RESET ALL 2009-03-19

Re: [PERFORM] Prepared statement does not exist

--- On Thu, 19/3/09, Nimesh Satam nimesh.z...@gmail.com wrote: We are receving the following error in the postgres database logs: 2009-03-19 02:14:20 PDT [2547]: [79-1] LOG: duration: 0.039 ms statement: RESET ALL 2009-03-19 02:14:20 PDT [2547]: [80-1] LOG: duration: 0.027 ms

Re: [PERFORM] please help with the explain analyze plan

Both queries are using your uid index on each of the partitions not generated_date, it's doing the generated_date with a filter on most of the partitions. This is except for on partition part_2006_02 in the second query where it uses your generated date index - and that takes the 80 secs.

Re: [PERFORM] scheduling autovacuum at lean hours only.

From: Rajesh Kumar Mallah mallah.raj...@gmail.com Is it possible to configure autovacuum to run only during certain hours ? We are forced to keep it off because it pops up during the peak query hours. AFAIK not directly within the conf. However you could probably set up a shell script to

Re: [PERFORM] suggestions for postgresql setup on Dell 2950 , PERC6i controller

--- On Fri, 6/2/09, Bruce Momjian br...@momjian.us wrote: Stupid question, but why do people bother with the Perc line of cards if the LSI brand is better? It seems the headache of trying to get the Perc cards to perform is not worth any money saved. I think in most cases the dell cards

Re: [PERFORM] suggestions for postgresql setup on Dell 2950 , PERC6i controller

--- On Thu, 5/2/09, Matt Burke mattbli...@icritical.com wrote: From: Matt Burke mattbli...@icritical.com Subject: Re: [PERFORM] suggestions for postgresql setup on Dell 2950 , PERC6i controller To: pgsql-performance@postgresql.org Date: Thursday, 5 February, 2009, 12:40 PM Arjen van

Re: [PERFORM] SSD performance

I spotted a new interesting SSD review. it's a $379 5.25 drive bay device that holds up to 8 DDR2 DIMMS (up to 8G per DIMM) and appears to the system as a SATA drive (or a pair of SATA drives that you can RAID-0 to get past the 300MB/s SATA bottleneck) Sounds very similar to the Gigabyte

Re: [PERFORM] caching written values?

A quick question, when pg receives data to be written to a table, does it cache that data in memory in case a subsequent request/query would need it? Afaik all pages are modified in memory, so the modified data would still be cached. -- Sent via pgsql-performance mailing list

Re: [PERFORM] understanding postgres issues/bottlenecks

--- On Sun, 11/1/09, Scott Marlowe scott.marl...@gmail.com wrote: They also told me we could never lose power in the hosting center because it was so wonder and redundant and that I was wasting my time. We'll that's just plain silly, at the very least there's always going to be some

Re: [PERFORM] understanding postgres issues/bottlenecks

--- On Thu, 8/1/09, Stefano Nichele stefano.nich...@gmail.com wrote: From: Stefano Nichele stefano.nich...@gmail.com Subject: Re: [PERFORM] understanding postgres issues/bottlenecks To: Scott Marlowe scott.marl...@gmail.com Cc: pgsql-performance@postgresql.org Date: Thursday, 8 January,

Re: [PERFORM] Fwd: Casting issue!!

--- On Wed, 7/1/09, jose fuenmayor jaf...@gmail.com wrote: Hi all I am trying to migrate from postgresql 8.2.x to 8.3.x, i have an issue with casting values when i try to perform the auto cast , it does not work and I get an error, how can i perform auto casting on 8.3 without

Re: [PERFORM] understanding postgres issues/bottlenecks

--- On Wed, 7/1/09, Scott Marlowe scott.marl...@gmail.com wrote: The really bad news is that you can't generally plug in a real RAID controller on a Dell. We put an Areca 168-LP PCI-x8 in one of our 1950s and it wouldn't even turn on, got a CPU Error. Hmm, I had to pull the perc5i's

Re: [PERFORM] understanding postgres issues/bottlenecks

--- On Wed, 7/1/09, Scott Marlowe scott.marl...@gmail.com wrote: Just to elaborate on the horror that is a Dell perc5e. We have one in a 1950 with battery backed cache (256 Meg I think). It has an 8 disk 500Gig SATA drive RAID-10 array and 4 1.6GHz cpus and 10 Gigs ram. Our perc5i

Re: [PERFORM] Perc 3 DC

--- On Mon, 24/11/08, Steve Clark [EMAIL PROTECTED] wrote: Yeah the battery's on it, that and the 128Mb is really the only reason I thought I'd give it a whirl. Is the battery functioning? We found that the unit had to be on and charged before write back caching would work. Yeah the

Re: [PERFORM] Perc 3 DC

--- Scott Marlowe [EMAIL PROTECTED] wrote: Yeah the battery is on there, and in the BIOS it says it's PRESENT and the status is GOOD. If I remember correctly, older LSI cards had pretty poor performance in RAID 1+0 (or any layered RAID really). Have you tried setting up RAID-1 pairs

[PERFORM] Perc 3 DC

Hi chaps, I've had this old card sitting on my desk for a while. It appears to be a U160 card with 128Mb BBU so I thought I'd wang it in my test machine (denian etch) and give it a bash. I set up 4 36Gb drives in raid 0+1, but I don't seem to be able to get more than 20MB/s write speed out of

Re: [PERFORM] Perc 3 DC

--- On Sat, 22/11/08, Scott Marlowe [EMAIL PROTECTED] wrote: You really have two choices. First is to try and use it as a plain SCSI card, maybe with caching turned on, and do the raid in software. Second is to cut it into pieces and make jewelry out of it. Haha, I'm not really into

Re: [PERFORM] Perc 3 DC

--- On Sat, 22/11/08, Scott Marlowe [EMAIL PROTECTED] wrote: I had an old workstation with a 4 port SATA card (no raid) running software raid and it handily stomps this 8 disk machine into the ground. Yeah, I think this machine will be going that route. We had a bunch of 18xx series servers

Re: [PERFORM] Filesystem benchmarking for pg 8.3.3 server

It feels like there is something fishy going on. Maybe the RAID 10 implementation on the PERC/6e is crap? It's possible. We had a bunch of perc/5i SAS raid cards in our servers that performed quite well in Raid 5 but were shite in Raid 10. I switched them out for Adaptec 5808s and

Re: [PERFORM] Mailing list hacked by spammer?

Most likely just a forged header or something, hardly hacked though is it. I think you need to do some training: http://www2.b3ta.com/bigquiz/hacker-or-spacker/ - Original Message From: Craig James [EMAIL PROTECTED] To: pgsql-performance@postgresql.org Sent: Friday, 18 July, 2008

Re: [PERFORM] Mailing list hacked by spammer?

Glyn Astill wrote: Most likely just a forged header or something, hardly hacked though is it. Yes, hack is the correct term. The bad guys have hacked into the major email systems, including gmail, which was the origin of this spam: http://www.theregister.co.uk/2008/02/25

[PERFORM] Adaptec 5805 SAS Raid

Any of you chaps used this controller? ___ Rise to the challenge for Sport Relief with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To

[PERFORM] Recomendations on raid controllers raid 1+0

Hi chaps, I'm looking at switching out the perc5i (lsi megaraid) cards from our Dell 2950s for something else as they're crap at raid 10. Thing is I'm not entirely sure where to start, we're using 6 SAS drives and also need a bbu cache. The perc5i has 256mb which I'm sure would be fine for us.

Re: [PERFORM] Recomendations on raid controllers raid 1+0

,+,+++,+,+++,+,+++,+,+++,+,+++,+,+++ - Original Message From: Guillaume Smet [EMAIL PROTECTED] To: Glyn Astill [EMAIL PROTECTED] Cc: pgsql-performance@postgresql.org Sent: Thursday, 13 March, 2008 3:58:41 PM Subject: Re: [PERFORM] Recomendations on raid controllers raid 1+0 Glyn, On Thu, Mar 13, 2008