Hi,
I had some disk io issues recently with NFS, I found the command 'iostat
-x 5' to be a great help when using Linux.
For example here is the output when I do a 10GB file transfer onto hdc
Device:rrqm/s wrqm/s r/s w/s rsec/s wsec/srkB/swkB/s
avgrq-sz avgqu-sz await svct
On Sun, 2005-05-29 at 16:17 -0400, Eric Lauzon wrote:
> So OID can be beneficial on static tables
OIDs aren't beneficial on "static tables"; unless you have unusual
requirements[1], there is no benefit to having OIDs on user-created
tables (see the default_with_oids GUC var, which will default to
On Sun, 2005-05-29 at 16:17 -0400, Eric Lauzon wrote:
> I am still in the dark due to my lack of knowledge on internal OID
> management,but
> i would presume that a table with OID enable and that has high load would
> require
> some more work from pgsql internal to maintain the OID index for the
"Eric Lauzon" <[EMAIL PROTECTED]> writes:
> I am still in the dark due to my lack of knowledge on internal OID
> management,but
> i would presume that a table with OID enable and that has high load would
> require
> some more work from pgsql internal to maintain the OID index for the database.
T
I am still in the dark due to my lack of knowledge on internal OID
management,but
i would presume that a table with OID enable and that has high load would
require
some more work from pgsql internal to maintain the OID index for the database.
So OID can be beneficial on static tables, or tables
Michael,
I'd recommend our contrib/pg_trgm module, which provides
trigram based fuzzy search and return results ordered by similarity
to your query. Read
http://www.sai.msu.su/~megera/postgres/gist/pg_trgm/README.pg_trgm
for more details.
Oleg
On Sun, 29 May 2005, Michael Engelhart wrote:
Hi
On Wed, May 25, 2005 at 09:29:36AM +0800, Christopher Kings-Lynne wrote:
> >--MSSQL's ability to hit the index only and not having
> >to go to the table itself results in a _big_
> >performance/efficiency gain. If someone who's in
> >development wants to pass this along, it would be a
> >nice addit
When I do an EXPLAIN ANALYZE on the above query, the result is:
Seq Scan on city_alias (cost=0.00..59282.31 rows=2 width=42) (actual
time=73.369..3330.281 rows=407 loops=1)
Filter: ((name)::text ~~ '%FRANCISCO'::text)
Total runtime: 3330.524 ms
(3 rows)
this is a query that our system n
On Sun, May 29, 2005 at 08:27:26AM -0500, Michael Engelhart wrote:
> this is a query that our system needs to do a LOT. Is there any way
> to improve the performance on this either with changes to our query
> or by configuring the database deployment? We have an index on
> city_name but w
Hi -
I have a table of about 3 million rows of city "aliases" that I need
to query using LIKE - for example:
select * from city_alias where city_name like '%FRANCISCO'
When I do an EXPLAIN ANALYZE on the above query, the result is:
Seq Scan on city_alias (cost=0.00..59282.31 rows=2 width
10 matches
Mail list logo
