>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 first run
> Sumeet Shukla writes:>
>> Yes, but when I actually execute
> 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 example also if possible.
>
> Regards,
> Daulat
Is there
- 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, that's what we do, but then to upgrade, we have to drop/add the
> node, because i
> 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
> slony1-95-2.2.2-1.rhel5.x86_64 rpm. I'm upgra
> From: Jim Nasby
>To: Jeff Janes ; Glyn Astill
>Cc: Pgsql-performance
>Sent: Wednesday, 2 December 2015, 22:32
>Subject: Re: [PERFORM] Index scan cost calculation
>
>
>On 11/30/15 5:03 PM, Jeff Janes wrote:
>> It thinks the combination of (show, type, best, bl
>
>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 pgsql-p
> From: Jeff Janes
> To: Glyn Astill
> Cc: Pgsql-performance
> Sent: Saturday, 28 November 2015, 19:25
> Subject: Re: [PERFORM] Index scan cost calculation
>
>
> Why does the index seats_index02 exist in the first place? It looks
> like an index designed for th
- Original Message -
> From: Tom Lane
> To: Glyn Astill
> Cc: Pgsql-performance
> Sent: Thursday, 26 November 2015, 16:44
> Subject: Re: [PERFORM] Index scan cost calculation
>
> Glyn Astill writes:
>> Using pg 9.4.5 I'm looking at a table set up b
- Original Message -
> From: Glyn Astill
> To: Pgsql-performance
> Sent: Thursday, 26 November 2015, 16:11
> Subject: [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
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 I'
> From: Huan Ruan
>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, therefore not avail
> From: Filip Rembiałkowski
>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 9.0.13
>
>to:
>ope
> From: Josh Berkus
>To: Scott Marlowe
>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 fsyncs or something
>> like that.
- Original Message -
> From: David Boreham
> To: "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 all o
>
> From: M. D.
>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 to ha
> From: Scott Marlowe
>On Mon, Apr 16, 2012 at 8:13 AM, Cesar Martin wrote:
>> Hi,
>>
>> Finally the problem was BIOS configuration. DBPM had was set to "Active
>> Power Controller" I changed this to "Max
>> Performance". http://en.community.dell.com/techcenter/power-cooling/w/wiki/best-practices
> From: Tomas Vondra
> 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).
>
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?
--- On Tue, 12/4/11, Greg Smith wrote:
> From: Greg Smith
> Subject: Re: [PERFORM] Linux: more cores = less concurrency.
> To: "Kevin Grittner"
> Cc: da...@lang.hm, "Steve Clark" , "Glyn Astill"
> , "Joshua D. Drake" , "Scott
>
--- On Tue, 12/4/11, Kevin Grittner 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 is that you don't ha
--- On Tue, 12/4/11, Merlin Moncure 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 n
--- On Mon, 11/4/11, Kevin Grittner wrote:
> From: Kevin Grittner
> Subject: Re: [PERFORM] Linux: more cores = less concurrency.
> To: da...@lang.hm, "Steve Clark" , "Kevin Grittner"
> , "Glyn Astill"
> Cc: "Joshua D. Drake" , "
--- On Tue, 12/4/11, Scott Marlowe wrote:
> From: Scott Marlowe
> Subject: Re: [PERFORM] Linux: more cores = less concurrency.
> To: "Glyn Astill"
> Cc: pgsql-performance@postgresql.org
> Date: Tuesday, 12 April, 2011, 6:55
> On Mon, Apr 11, 2011 at 7:04 AM, Glyn
&g
--- On Tue, 12/4/11, Merlin Moncure 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 ((
--- On Mon, 11/4/11, Scott Marlowe wrote:
> From: Scott Marlowe
> Subject: Re: [PERFORM] Linux: more cores = less concurrency.
> To: "Glyn Astill"
> Cc: "Kevin Grittner" , "Joshua D. Drake"
> , pgsql-performance@postgresql.org
> Date: Monday,
--- On Mon, 11/4/11, da...@lang.hm wrote:
> From: da...@lang.hm
> Subject: Re: [PERFORM] Linux: more cores = less concurrency.
> To: "Steve Clark"
> Cc: "Scott Marlowe" , "Joshua D. Drake"
> , "Kevin Grittner" ,
> pgsql-performan
--- On Mon, 11/4/11, Scott Marlowe 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 the 5500 tps range
--- On Mon, 11/4/11, Joshua D. Drake wrote:
> From: Joshua D. Drake
> Subject: Re: [PERFORM] Linux: more cores = less concurrency.
> To: "Kevin Grittner"
> Cc: pgsql-performance@postgresql.org, "Glyn Astill"
> Date: Monday, 11 April, 2011, 19:12
&
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 individ
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
o
--- On Thu, 3/2/11, Greg Smith 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
> http://www.newegg.com/Product/Product.aspx?Item=N
--- On Fri, 25/12/09, Scott Marlowe 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 that way by my curr
--- On Tue, 24/11/09, Scott Marlowe wrote:
> Jochen Erwied
>
> 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 Technology Supertrak ES4650 + additional
> BB
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 sort
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
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 wrote:
> From: Craig James
> Subject: [PERFORM] Used computers?
> To: pgsql-performance@postgresql.org
> Date:
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 wrote:
> From: Alan McK
--- On Mon, 13/4/09, Greg Smith wrote:
> From: Greg Smith
> Subject: Re: [PERFORM] 2.6.26 kernel and PostgreSQL
> To: "Glyn Astill"
> Cc: pgsql-performance@postgresql.org, "Kevin Grittner"
>
> Date: Monday, 13 April, 2009, 9:25 AM
> On Fri, 10
--- On Fri, 10/4/09, Kevin Grittner wrote:
> Glyn Astill 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 being a bit
>
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 to
--- On Fri, 20/3/09, Nimesh Satam wrote:
> From: Nimesh Satam
> > > 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]: [8
--- On Thu, 19/3/09, Nimesh Satam 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 statement:
> SE
> From: Rajesh Kumar Mallah
> 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 turn it on and off
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.
--- On Fri, 6/2/09, Bruce Momjian 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 actually cost
--- On Thu, 5/2/09, Matt Burke wrote:
> From: Matt Burke
> 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 der Meijden wrote:
>
> > Afaik the Perc 5/i
> 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 Giga
>
> 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 (pg
--- On Sun, 11/1/09, Scott Marlowe 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 breakers / fuzes in between
--- On Thu, 8/1/09, Stefano Nichele wrote:
> From: Stefano Nichele
> Subject: Re: [PERFORM] understanding postgres issues/bottlenecks
> To: "Scott Marlowe"
> Cc: pgsql-performance@postgresql.org
> Date: Thursday, 8 January, 2009, 8:36 AM
> Find !
>
> Dell CERC SATA RAID 2 PCI SATA 6ch
>
> Ru
--- On Wed, 7/1/09, Scott Marlowe 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 controllers performed be
--- On Wed, 7/1/09, Scott Marlowe 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 out of our dell s
--- On Wed, 7/1/09, jose fuenmayor 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
> rewrite my sour
--- 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
--- 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
--- 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 serv
--- 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
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
> >
> >> 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
> 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://ww
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,
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 mak
,+,+++,+,+++,+,+++,+,+++,+,+++,+,+++
- 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
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.
W
64 matches
Mail list logo
