On 6 April 2011 05:44, Tom Lane wrote:
> Thom Brown writes:
>> The index doesn't get used. There's probably a logical explanation,
>> which is what I'm curious about.
>
> Er ... it's broken?
>
> It looks like the index predicate expression isn't getting the right
> collation assigned, so predtes
On 6 April 2011 00:02, Kenneth Marshall wrote:
> The stats seem off. Are you certain that an analyze has run?
>
> Cheers,
> Ken
>
Yes, an ANALYZE was definitely run against the table.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: h
On Apr 5, 2011, at 9:33 AM, Adarsh Sharma wrote:
> Now I have to start more queries on Database Server and issue new connections
> after some time. Why the cached memory is not freed.
It's freed on-demand.
> Flushing the cache memory is needed & how it could use so much if I set
Why would forc
Would really appreciate someone taking a look at the query below
Thanks in advance!
this is on a linux box...
Linux dsrvr201.larc.nasa.gov 2.6.18-164.9.1.el5 #1 SMP Wed Dec 9
03:27:37 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
explain analyze
select MIN(IV.STRTDATE), MAX(IV.ENDDATE)
from G
On 5 April 2011 21:25, Maria L. Wilson wrote:
> Would really appreciate someone taking a look at the query below
> Thanks in advance!
>
>
> this is on a linux box...
> Linux dsrvr201.larc.nasa.gov 2.6.18-164.9.1.el5 #1 SMP Wed Dec 9 03:27:37
> EST 2009 x86_64 x86_64 x86_64 GNU/Linux
>
> expl
> some additional info.
> the table inventory is about 4481 MB and also has postgis types.
> the table gran_ver is about 523 MB
> the table INVSENSOR is about 217 MB
>
> the server itself has 32G RAM with the following set in the postgres conf
> shared_buffers = 3GB
> work_mem = 64MB
> maintena
Autovacuum is not running - but regular vacuums are being done twice daily.
indexes on inventory:
CREATE INDEX inven_idx1
ON inventory
USING btree
(inv_id);
CREATE UNIQUE INDEX inven_idx2
ON inventory
USING btree
(granule_id);
indexes on gran_ver:
CREATE UNIQUE INDEX granver_idx1
thanks for the reply, Tomas. I'll test bumping up work_mem and see how
that helps.
thanks again, Maria Wilson
On 4/6/11 9:16 AM, t...@fuzzy.cz wrote:
some additional info.
the table inventory is about 4481 MB and also has postgis types.
the table gran_ver is about 523 MB
the table IN
"Maria L. Wilson" wrote:
> Autovacuum is not running - but regular vacuums are being done
> twice daily.
Is the ANALYZE keyword used on those VACUUM runs? What version of
PostgreSQL is this. If it's enough to need fsm settings, do you run
with the VERBOSE option and check the end of the outp
Dne 6.4.2011 17:33, Kevin Grittner napsal(a):
> "Maria L. Wilson" wrote:
>
>> Autovacuum is not running - but regular vacuums are being done
>> twice daily.
>
> Is the ANALYZE keyword used on those VACUUM runs? What version of
> PostgreSQL is this. If it's enough to need fsm settings, do you
Dne 4.4.2011 16:32, Kevin Grittner napsal(a):
> Nothing there makes a write glut on checkpoint less likely to be the
> cause. Without a BBU write-back cache it is actually *more* likely,
> and having enough RAM to hold the whole database makes it *more*
> likely. If you haven't placed your pg_xlo
I have generation 1 and 2 Intel MLC drives in production (~150+). Some
have been around for 2 years.
None have died. None have hit the write cycle limit. We do ~ 75GB of
writes a day.
The data and writes on these are not transactional (if one dies, we have
copies). But the reliability has bee
--- On Wed, 4/6/11, Scott Carey wrote:
> I could care less about the 'fast' sandforce drives.
> They fail at a high
> rate and the performance improvement is BECAUSE they are
> using a large,
> volatile write cache.
The G1 and G2 Intel MLC also use volatile write cache, just like most SandF
Hello,
I saw some recommendations from people on the net not to use background fsck when running PostgreSQL
on FreeBSD. As I recall, these opinions were just thoughts of people which they shared with the
community, following their bad experience caused by using background fsck. So, not coming a
On Wed, Apr 6, 2011 at 4:33 PM, Ireneusz Pluta wrote:
> Hello,
>
> I saw some recommendations from people on the net not to use background fsck
> when running PostgreSQL on FreeBSD. As I recall, these opinions were just
> thoughts of people which they shared with the community, following their bad
But waiting so much time (like now) during foreground fsck of a large data
filesystem after unclean shutdown, makes me to come to this group to ask
whether I really need to avoid background fsck on a PostgreSQL machine?
Could I hear your opinions?
Shouldn't a journaling file system just come bac
Not for user data, only controller data.
Original message
>Date: Wed, 6 Apr 2011 14:11:10 -0700 (PDT)
>From: pgsql-performance-ow...@postgresql.org (on behalf of Andy
>)
>Subject: Re: [PERFORM] Intel SSDs that may not suck
>To: Merlin Moncure ,Scott Carey
>Cc: "pgsql-performance@po
On 3/29/11 7:16 AM, "Jeff" wrote:
>
>The write degradation could probably be monitored looking at svctime
>from sar. We may be implementing that in the near future to detect
>when this creeps up again.
For the X25-M's, overcommit. Do a secure erase, then only partition and
use 85% or so of t
On 3/29/11 7:32 AM, "Jeff" wrote:
>
>On Mar 29, 2011, at 10:16 AM, Jeff wrote:
>
>> Now that all sounds awful and horrible until you get to overall
>> performance, especially with reads - you are looking at 20k random
>> reads per second with a few disks. Adding in writes does kick it
>> down
On 4/6/11 2:11 PM, "Andy" wrote:
>
>--- On Wed, 4/6/11, Scott Carey wrote:
>
>
>> I could care less about the 'fast' sandforce drives.
>> They fail at a high
>> rate and the performance improvement is BECAUSE they are
>> using a large,
>> volatile write cache.
>
>The G1 and G2 Intel MLC also u
On 4/6/11 4:03 PM, "gnuo...@rcn.com" wrote:
>Not for user data, only controller data.
>
False. I used to think so, but there is volatile write cache for user
data -- its on the 256K chip SRAM not the DRAM though.
Simple power failure tests demonstrate that you lose data with these
drives unl
On 4/5/11 7:07 AM, "Merlin Moncure" wrote:
>On Mon, Apr 4, 2011 at 8:26 PM, Greg Smith wrote:
>>
>> If you really don't need more than 120GB of storage, but do care about
>> random I/O speed, this is a pretty easy decision now--presuming the
>>drive
>> holds up to claims. As the claims are rea
On Wed, Apr 6, 2011 at 5:42 PM, Scott Carey wrote:
> On 4/5/11 7:07 AM, "Merlin Moncure" wrote:
>>One thing about MLC flash drives (which the industry seems to be
>>moving towards) is that you have to factor drive lifespan into the
>>total system balance of costs. Data point: had an ocz vertex 2
On 04/06/2011 08:22 PM, Scott Carey wrote:
Simple power failure tests demonstrate that you lose data with these
drives unless you disable the cache. Disabling the cache roughly drops
write performance by a factor of 3 to 4 on G1 drives and significantly
hurts wear-leveling and longevity (I haven
Here's the new Intel 3rd generation 320 series drive:
$ sudo smartctl -i /dev/sdc
Device Model: INTEL SSDSA2CW120G3
Firmware Version: 4PC10302
User Capacity:120,034,123,776 bytes
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4
Since I have to go chant at the unbelievers next w
Had to say a quick thanks to Greg and the others who have posted
detailed test results on SSDs here.
For those of us watching for the inflection point where we can begin the
transition from mechanical to solid state storage, this data and
experience is invaluable. Thanks for sharing it.
A shor
SSDs have been around for quite some time. The first that I've found is Texas
Memory. Not quite 1977, but not flash either, although they've been doing so
for a couple of years.
http://www.ramsan.com/company/history
Original message
>Date: Wed, 06 Apr 2011 20:56:16 -0600
>From: pg
On 4/6/2011 9:19 PM, gnuo...@rcn.com wrote:
SSDs have been around for quite some time. The first that I've found is Texas
Memory. Not quite 1977, but not flash either, although they've been doing so
for a couple of years.
Well, I built my first ram disk (which of course I thought I had
inven
On 2011-03-28 22:21, Greg Smith wrote:
Some may still find these two cheap for enterprise use, given the use
of MLC limits how much activity these drives can handle. But it's
great to have a new option for lower budget system that can tolerate
some risk there.
Drifting of the topic slightly
On 04/07/2011 12:27 AM, Jesper Krogh wrote:
On 2011-03-28 22:21, Greg Smith wrote:
Some may still find these two cheap for enterprise use, given the use
of MLC limits how much activity these drives can handle. But it's
great to have a new option for lower budget system that can tolerate
some
Thom Brown writes:
> On 6 April 2011 05:44, Tom Lane wrote:
>> It looks like the index predicate expression isn't getting the right
>> collation assigned, so predtest.c decides the query doesn't imply the
>> index's predicate. Too tired to look into exactly why right now, but
>> it's clearly bou
31 matches
Mail list logo
