Re: [PERFORM] Fusion-io ioDrive

On 02/07/2008, Jeffrey Baker <[EMAIL PROTECTED]> wrote: > Yeah. The manufacturer rates it for 5 years in constant use. I > remain skeptical. I read in one of their spec-sheets that w/ continuous writes it should survive roughly 3.4 years ... I'd be a tad more conservative, I guess, and try to dr

Re: [PERFORM] Fusion-io ioDrive

On Tue, 1 Jul 2008, Jeffrey Baker wrote: The only real problem with this benchmark is that the machine became CPU-limited rather quickly. During the runs with the ioDrive, iowait was pretty well zero, with user CPU being about 75% and system getting about 20%. You might try reducing the numb

Re: [PERFORM] Fusion-io ioDrive

On Tue, Jul 1, 2008 at 6:17 PM, Andrej Ricnik-Bay <[EMAIL PROTECTED]> wrote: > On 02/07/2008, Jeffrey Baker <[EMAIL PROTECTED]> wrote: > >> Red Hat and its clones. The other problem is the 80GB model is too >> small to hold my entire DB, Although it could be used as a tablespace >> for some cri

Re: [PERFORM] Fusion-io ioDrive

On 02/07/2008, Jeffrey Baker <[EMAIL PROTECTED]> wrote: > Red Hat and its clones. The other problem is the 80GB model is too > small to hold my entire DB, Although it could be used as a tablespace > for some critical tables. But hey, it's fast. And when/if it dies, please give us a rough gues

[PERFORM] Fusion-io ioDrive

I recently got my hands on a device called ioDrive from a company called Fusion-io. The ioDrive is essentially 80GB of flash on a PCI card. It has its own driver for Linux completely outside of the normal scsi/sata/sas/fc block device stack, but from the user's perspective it behaves like a block

Re: [PERFORM] Select running slow on Postgres

On Tue, Jul 1, 2008 at 1:29 PM, samantha mahindrakar <[EMAIL PROTECTED]> wrote: > Hi > I have a select statement that runs on a partition having say couple > million rows. > The tabel has indexes on two colums. However the query uses the > non-indexed colums too in its where clause. > For example:

[PERFORM] Select running slow on Postgres

Hi I have a select statement that runs on a partition having say couple million rows. The tabel has indexes on two colums. However the query uses the non-indexed colums too in its where clause. For example: SELECT lane_id,measurement_start, measurement_end,speed,volume,occupancy,quality,effective_d

Re: [PERFORM] Does max size of varchar influence index size

Franck Routier wrote: Le lundi 30 juin 2008 à 13:24 -0700, Mark Roberts a écrit : Hi Mark, Is there any particular reason that you're not using a surrogate key? Well, human readability is the main reason, no standard way to handle sequences between databases vendors being the second... (and

Re: [PERFORM] VACUUM ANALYZE blocking both reads and writes to a table

> > (2) If it's autovacuum we're talking about, it will get kicked off the > > table if anyone else comes along and wants a conflicting lock. > > Not on 8.2 though. That is also nice to know. One more reason to upgrade to 8.3. Thank you very much, both Alvaro and Tom, for the very insightful dis

Re: [PERFORM] Does max size of varchar influence index size

Le lundi 30 juin 2008 à 13:24 -0700, Mark Roberts a écrit : Hi Mark, > Is there any particular reason that you're not using a surrogate key? Well, human readability is the main reason, no standard way to handle sequences between databases vendors being the second... (and also problems when copyi

Re: [PERFORM] Inact_dirty is increasing continuously and causing the system to hang.

On Tue, 1 Jul 2008, Kathirvel, Jeevanandam wrote: We are seeing system hang-up issue when we do continuous update on table ( 2-3 records/sec) within 10-12 hours. Memory parameter Inact_dirty( shown in /proc/meminfo) is increasing continuously and causing the system to hang-up(not responding st

Re: [PERFORM] un-understood index performance behaviour

"Emiliano Leporati" <[EMAIL PROTECTED]> writes: > can anybody explain me why this happens ? and if i should try different > indexes ? Showing EXPLAIN ANALYE output would probably make things a lot clearer. regards, tom lane -- Sent via pgsql-performance mailing list (pgs

Re: [PERFORM] un-understood index performance behaviour

On Tue, Jul 1, 2008 at 4:49 AM, Emiliano Leporati <[EMAIL PROTECTED]> wrote: > Hi, > i have a table with a huge amount of rows (actually 4 millions and a half), > defined like this: > > CREATE TABLE rtp_frame ( > i_len integer NOT NULL, > i_file_offset bigint NOT NULL, > i_file_id integ

[PERFORM] Inact_dirty is increasing continuously and causing the system to hang.

Hi, We are seeing system hang-up issue when we do continuous update on table ( 2-3 records/sec) within 10-12 hours. Memory parameter Inact_dirty( shown in /proc/meminfo) is increasing continuously and causing the system to hang-up(not responding state). This issue is not happening when

[PERFORM] un-understood index performance behaviour

Hi, i have a table with a huge amount of rows (actually 4 millions and a half), defined like this: CREATE TABLE rtp_frame ( i_len integer NOT NULL, i_file_offset bigint NOT NULL, i_file_id integer NOT NULL, -- foreign key i_timestamp bigint NOT NULL, i_loop integer NOT NULL,