Curt Sampson [EMAIL PROTECTED] writes:
On Sat, 23 Oct 2004, Tom Lane wrote:
Seems to me the overhead of any such scheme would swamp the savings from
avoiding kernel/userspace copies ...
Well, one really can't know without testing, but memory copies are
extremely expensive if they go outside
Hi,
Has anybody got any ideas on my
recent posting ? (thanks in advance) :-
I have a problem
where a query inside a function is up to 100 times slower inside a function than
as a stand alone query run in psql.
The column
'botnumber' isa character(10), is indexed and there are 125000
Rod Dutton wrote:
Hi,
Has anybody got any ideas on my recent posting ? (thanks in advance) :-
I have a problem where a query inside a function is up to 100 times
slower inside a function than as a stand alone query run in psql.
The column 'botnumber' is a character(10), is indexed and
Rod Dutton wrote:
Thank John,
I am running Postgres 7.3.7 on a Dell PowerEdge 6600 Server with Quad Xeon
2.7GHz processors with 16GB RAM and 12 x 146GB drives in Raid 10 (OS, WAL,
Data all on separate arrays).
You might want think about upgraded to 7.4, as I know it is better at
quite a few
Rod Dutton wrote:
I also should add that the sp is only slow when the table is big (probably
obvious!).
Rod
Sure, the problem is it is switching to a sequential search, with a lot
of rows, versus doing an indexed search.
It's all about trying to figure out how to fix that, especially for any
I was looking into another problem, and I found something that surprised
me. If I'm doing SELECT * FROM mytable WHERE col = 'myval' LIMIT 1..
Now col is indexed, by mytable has 500,000 rows, and 'myval' occurs
maybe 100,000 times. Without the LIMIT, this query should definitely do
a sequential
John Meinel [EMAIL PROTECTED] writes:
I was looking into another problem, and I found something that surprised
me. If I'm doing SELECT * FROM mytable WHERE col = 'myval' LIMIT 1..
Now col is indexed, by mytable has 500,000 rows, and 'myval' occurs
maybe 100,000 times. Without the LIMIT, this
Tom Lane wrote:
John Meinel [EMAIL PROTECTED] writes:
I was looking into another problem, and I found something that surprised
me. If I'm doing SELECT * FROM mytable WHERE col = 'myval' LIMIT 1..
Now col is indexed, by mytable has 500,000 rows, and 'myval' occurs
maybe 100,000 times. Without the
Hi,
I have had some
performance problems recently on very large tables (10s of millions of
rows). A vacuum full did make a large improvement and then dropping
re-creating the indexes also was very beneficial. My performance problem
has now been solved.
My question is: will
using the
Rod Dutton [EMAIL PROTECTED] writes:
My question is: will using the contrib/reindexdb or REINDEX sql command do
essentially the same job as dropping and re-creating the indexes. I.E. do
you get a fully compacted and balanced index?
Yes.
How is concurrency handled by contrib/reindexdb and
On Sun, 24 Oct 2004, Tom Lane wrote:
Well, one really can't know without testing, but memory copies are
extremely expensive if they go outside of the cache.
Sure, but what about all the copying from write queue to page?
There's a pretty big difference between few-hundred-bytes-on-write and
Curt Sampson [EMAIL PROTECTED] writes:
I see the OS issues related to mapping that much memory as a much bigger
potential problem.
I see potential problems everywhere I look ;-)
Considering that the available numbers suggest we could win just a few
percent (and that's assuming that all this
On Sun, 24 Oct 2004, Tom Lane wrote:
Considering that the available numbers suggest we could win just a few
percent...
I must confess that I was completely unaware of these numbers. Where
do I find them?
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.NetBSD.org
13 matches
Mail list logo
