Tom Lane wrote:
"Craig A. James" <[EMAIL PROTECTED]> writes:
CREATE OR REPLACE FUNCTION cansmiles(text) RETURNS text
AS '/usr/local/pgsql/lib/libchem.so', 'cansmiles'
LANGUAGE 'C' STRICT IMMUTABLE;
Umm ... this is a single-argument function.
db=> explain analyze select version_id, 'Brc
"Craig A. James" <[EMAIL PROTECTED]> writes:
> CREATE OR REPLACE FUNCTION cansmiles(text) RETURNS text
> AS '/usr/local/pgsql/lib/libchem.so', 'cansmiles'
> LANGUAGE 'C' STRICT IMMUTABLE;
Umm ... this is a single-argument function.
> db=> explain analyze select version_id, 'Brc1ccc2nc(cn2c1
Adam Rich wrote:
Craig,
What version of postgres are you using? I just tested this on PG 8.1.2
and was unable to reproduce these results. I wrote a simple function
that returns the same text passed to it, after sleeping for 1 second.
I use it in a where clause, like your example below, and rega
Craig,
What version of postgres are you using? I just tested this on PG 8.1.2
and was unable to reproduce these results. I wrote a simple function
that returns the same text passed to it, after sleeping for 1 second.
I use it in a where clause, like your example below, and regardless of
the numb
Well, once again I'm hosed because there's no way to tell the optimizer the
cost for a user-defined function. I know this issue has already been raised
(by me!) several times, but I have to remind everyone about this. I frequently
must rewrite my SQL to work around this problem.
Here is the
Le jeudi 4 janvier 2007 00:18, Magnus Hagander a écrit :
> But to get a good answer on if the difference is
> significant enough to matter, you really need to run some kind of simple
> benchmark on *your* workload.
To easily stress test a couple of servers and compare results on *your*
workload,
Jeremy Haile wrote:
> I am sure that this has been discussed before, but I can't seem to find
> any recent posts. (I am running PostgreSQL 8.2)
>
> I have always ran PostgreSQL on Linux in the past, but the company I am
> currently working for uses Windows on all of their servers. I don't
> have
Tom Lane wrote:
Erik Jones <[EMAIL PROTECTED]> writes:
That's a good idea, but first I'll still need to run it by my sysadmin
wrt space -- our dump files are around 22GB when we can let them finish
these days.
Given that we're now speculating about regex problems, you could do a
test
Erik Jones <[EMAIL PROTECTED]> writes:
> That's a good idea, but first I'll still need to run it by my sysadmin
> wrt space -- our dump files are around 22GB when we can let them finish
> these days.
Given that we're now speculating about regex problems, you could do a
test run of "pg_dump -s" w
Tom Lane wrote:
Erik Jones <[EMAIL PROTECTED]> writes:
Guillaume Smet wrote:
Could you set log_min_duration_statement=0 on your server and enable
Heh, unfortunately, setting log_min_duration_statement=0 would be a
total last resort as the last we counted (2 months ago) we w
I am sure that this has been discussed before, but I can't seem to find
any recent posts. (I am running PostgreSQL 8.2)
I have always ran PostgreSQL on Linux in the past, but the company I am
currently working for uses Windows on all of their servers. I don't
have the luxury right now of running
Erik Jones <[EMAIL PROTECTED]> writes:
> Guillaume Smet wrote:
>> Could you set log_min_duration_statement=0 on your server and enable
> Heh, unfortunately, setting log_min_duration_statement=0 would be a
> total last resort as the last we counted (2 months ago) we were doing
> approximately 3 m
Guillaume Smet wrote:
Erik,
Could you set log_min_duration_statement=0 on your server and enable
logging (tutorial here if you don't know how to do that:
http://pgfouine.projects.postgresql.org/tutorial.html).
You should see which queries are executed in both cases and find the
slow one easily.
Tom Lane wrote:
Erik Jones <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I could see this taking an unreasonable amount of time if you had a huge
number of pg_class rows or a very long search_path --- is your database
at all out of the ordinary in those ways?
Well, running "selec
Erik Jones <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I could see this taking an unreasonable amount of time if you had a huge
>> number of pg_class rows or a very long search_path --- is your database
>> at all out of the ordinary in those ways?
>>
> Well, running "select count(*) from pg_c
Erik,
Could you set log_min_duration_statement=0 on your server and enable
logging (tutorial here if you don't know how to do that:
http://pgfouine.projects.postgresql.org/tutorial.html).
You should see which queries are executed in both cases and find the
slow one easily.
Regards,
--
Guillaum
Tom Lane wrote:
Erik Jones <[EMAIL PROTECTED]> writes:
...
sigaction(SIGPIPE, 0x08046E20, 0x08046E70) = 0
send(4, " Q\0\0\0E5 S E L E C T ".., 230, 0) = 230
<--- Hang is
right here!
sigaction(SIGPIPE, 0x08046E20, 0x08046E70
Erik Jones <[EMAIL PROTECTED]> writes:
> ...
> sigaction(SIGPIPE, 0x08046E20, 0x08046E70) = 0
> send(4, " Q\0\0\0E5 S E L E C T ".., 230, 0) = 230
> <--- Hang is
> right here!
> sigaction(SIGPIPE, 0x08046E20, 0x08046E70) = 0
Tom Lane wrote:
Erik Jones <[EMAIL PROTECTED]> writes:
Hmm... This gets stranger and stranger. When connecting to the
database with the psql client in 8.2's bin directory and using commands
such as \d the client hangs, or takes an extremely long time.
Hangs at what point? During co
=?iso-8859-1?q?Rolf=20=D8stvik?= <[EMAIL PROTECTED]> writes:
> Index Scan using step_result_uut_result_idx on step_result_subset
> (cost=0.00..563.85 rows=23
> width=4) (actual time=0.069..0.069 rows=0 loops=1)
>Index Cond: (uut_result = $1)
>Filter: (step_parent = 0)
> Total runtime: 0
--- Tom Lane <[EMAIL PROTECTED]> skrev:
>
> Please --- I'm still curious why the estimated cost changed so much from
> 7.4 to 8.2. I can believe a marginal change in cost leading to a plan
Is this the output you need?
logistics_82=# prepare foo(int) as select id from step_result_subset where
21 matches
Mail list logo
