Hi,
I am not sure if it is bug or not but I found some strange behaviour. Maybe
it is the same as described on
http://www.postgresql.org/message-id/14616.1244317...@sss.pgh.pa.us ?). If
yes - I'm sorry for the trouble, but I think that my example is more
obvious.
Tested on PostgreSQL 9.2.4
Hi,
I am not sure if it is bug or not but I found some strange behaviour. Maybe
it is the same as described on
http://www.postgresql.org/message-id/14616.1244317...@sss.pgh.pa.us ?). If
yes - I'm sorry for the trouble, but I think that my example is more
obvious.
Tested on PostgreSQL 9.2.4
Hi,
I have PostgreSQL 9.0.12 on Windows.
I have some simple function:
CREATE OR REPLACE FUNCTION sfunction() RETURNS BOOL AS
$BODY$
DECLARE
q TEXT;
r RECORD;
BEGIN
q='SELECT 1 from tb_klient LIMIT 0';
FOR r IN EXECUTE q
LOOP
END LOOP;
RETURN NULL;
RETURN NUL
>> I would like to create some application using triggers and
>> LISTEN/NOTIFY framework. I've tested it, and I noticed that
>> performance of NOTIFY significally decreases with increasing number of
>> distinct NOTIFIES in transaction.
>> I found that function AsyncExistsPendingNotify is respons
Hello,
I would like to create some application using triggers and LISTEN/NOTIFY
framework. I've tested it, and I noticed that performance of NOTIFY
significally decreases with increasing number of distinct NOTIFIES in
transaction.
I found that function AsyncExistsPendingNotify is responsibe for
> Looks like you've almost re-invented the trigram module:
> http://www.postgresql.org/docs/9.0/static/pgtrgm.html
I didn't know about this module.
Idea to use three letters strings and use Full Text Search is the same, but
the rest is not.
Is the idea to use similarity for this problem is real
>How can we boost performance of queries containing pattern matching
>characters? In my case, we're using a percent sign (%) that matches any
string of zero or more characters.
>
> QUERY: DELETE FROM MYTABLE WHERE EMAIL ILIKE '%domain.com%'
>
> EMAIL column is VARCHAR(256).
>
> As it is clear
> I've changed default_statistics_target to 1 and I think that is a
> reason.
> That's certainly going to cost you something, but this seems like a mighty
large slowdown, especially for a non-join query. What datatype is te.idtr,
anyway?
Integer not null and primary key of t_positions tab
2010/11/15 Artur Zając :
> Why there is so big difference between explain analyze (0.710 ms) and
> real execution time (3309 ms)? Any suggestions?
> Could it be that it takes a long time to plan for some reason? How fast
is a plain EXPLAIN?
Yes! That is it :) Planning is painfu
> EXPLAIN ANALYZE doesn't account for all of the runtime involved. In this
case, I'd bet that session startup/shutdown is a big part of the difference.
>
> regards, tom lane
Does session startup/shutdown depend on tables used in query? Some simpler
query:
time psql -c 'e
I have some simple query (executed with time command):
time psql -c 'explain analyze SELECT te.idt FROM t_positions AS te JOIN
t_st AS stm ON (te.idt=stm.idt AND 4=stm.idm) WHERE te.idtr IN (347186)'
QUERY
PLAN
11 matches
Mail list logo
