Re: [PERFORM] pg_reset_stats + cache I/O %

On Wed, Mar 08, 2006 at 01:35:35PM -0500, mcelroy, tim wrote: > I actually need this info as I was tasked by management to provide it. Not > sure if they understand that or not, I do but management does like to see > how well the system and its components are performing. Also, I would > utilize t

[PERFORM] embedded postgres and threading

Sorry if this is the wrong list ... I'm in the process of developing an application based on gtk & postgress for both windows & linux. Short, simple and to the point - I'm using embedded SQL is there anything I should know about using postgress in multiple threads, under linux OR wind

Re: [PERFORM] Postgres and Ingres R3 / SAN

Adding -performance back; you should do a reply-all if you want to reply to list messages. > From: Jeremy Haile [mailto:[EMAIL PROTECTED] > > Can you point us at more info about this? I can't even find > a website > > for Ingres... > > Ingres is based off of the same original codebase that Post

Re: [PERFORM] Is good idea an array of 365 elements in a cell of a table, in order to perform searchs?

If you need to compare stuff on a day-by-day basis, I think you'll be much better off just expanding stuff into a table of: item_id int NOT NULL , day date NOT NULL , capacitiy ... , price_per_day ... , price_per_week ... , PRIMARY KEY( item_id, day ) (Note that camel case and databases

Re: [PERFORM] pg_reset_stats + cache I/O %

Title: RE: [PERFORM] pg_reset_stats + cache I/O % I actually need this info as I was tasked by management to provide it.  Not sure if they understand that or not, I do but management does like to see how well the system and its components are performing.  Also, I would utilize these results to

Re: [PERFORM] pg_reset_stats + cache I/O %

Out of curiosity, why do you want this info? More important, do the folks who are looking at this understand that a key part of PostgreSQL's tuning strategy is to let the OS handle the bulk of the caching? On Wed, Mar 08, 2006 at 08:59:51AM -0500, mcelroy, tim wrote: > Thanks Tom, sorry I neglecte

Re: [PERFORM] Bad row estimates

Alex Adriaanse <[EMAIL PROTECTED]> writes: > Its row estimates are still way off. As a matter of fact, it almost seems as > if the index doesn't affect row estimates at all. Indexes normally don't affect estimates. Expression indexes do effectively create a new column to generate stats for, but

Re: [PERFORM] Bad row estimates

Thank you all for your valuable input. I have tried creating a partial index, a GIST index, and a GIST + partial index, as suggested, but it does not seem to make a significant difference. For instance: CREATE INDEX test_table_1_interval_idx ON test_table_1 USING GIST (box(point(start_ts::

[PERFORM] Is good idea an array of 365 elements in a cell of a table, in order to perform searchs?

Hi, Im having a dude with a new inplementation in a web site. The ojective is create a search as fast as possible. I have thought two possibilities to do that: I have several items. Those items has 1 or more of capacity. Each capacity, has several dates (From 1 january to 10 of april, for ex

Re: [PERFORM] pg_reset_stats + cache I/O %

Title: RE: [PERFORM] pg_reset_stats + cache I/O % Thanks Tom, sorry I neglected to copy the list on my previous email. Does this query make sense and is it valid for an accurate cache % hit ratio for the entire DB?  I would assume I could use the same logic with other views such as pg_s