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
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 there are 12
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 t
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 things
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
va
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 sequenti
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 LI
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. Withou
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/reindexd
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-writ
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
