--- 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
=?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 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
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:
...
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,
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
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
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
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.
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
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
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
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:
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
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
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,
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
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
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 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
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
21 matches
Mail list logo
