Vitaly,
> I have a problem with certain queries performance. Trouble is that
> while their execution plan is pretty good and mostly their execution
> is great as well, their FIRST execution time (that is after you mount
> the database) is abysmal.
This is a well-known problem. The general appro
I have a problem with certain queries performance. Trouble is that
while their execution plan is pretty good and mostly their execution
is great as well, their FIRST execution time (that is after you mount
the database) is abysmal.
I realize that it happens due to the loading of data from the HD t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
| Gaetano Mendola <[EMAIL PROTECTED]> wrote ..
|
|>Hi all,
|>do you know any clean workaround at ill-planned queries inside a stored
|>procedure?
| I use "EXECUTE" inside a stored procedure for just this purpose. This is
| not t
I use "EXECUTE" inside a stored procedure for just this purpose. This is not the same
as PREPARE/EXECUTE, it lets you send an arbitrary string as SQL within the procedure.
You have to write the query text on the fly in the procedure, which can be a little
messy with quoting and escaping.
Gaetan
Greg Stark wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Don't you think this will permit also to avoid extra disk seek and cache
invalidation? If you are updating the row (0,1) I think is less expensive
put the new version in (0,2) instead of thousand line far from that point.
Well if the oth
Hi all,
do you know any clean workaround at ill-planned queries inside a stored procedure?
Let me explain with an example:
empdb=# select count(*) from user_logs;
count
-
5223837
(1 row)
empdb=# select count(*) from user_logs where id_user = 5024;
count
239453
(1 row)
empdb=#
First things first: try vacuum full analyze on all the tables involved.
1. Should I afraid of high cost indexes? Or query will still be very efficient?
Not necessarily. However, EXPLAIN output is pretty much useless for us
for helping you. You need to post EXPLAIN ANALYZE output.
Then, you nee
Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Don't you think this will permit also to avoid extra disk seek and cache
> > invalidation? If you are updating the row (0,1) I think is less expensive
> > put the new version in (0,2) instead of thousand line far from that point.
Well if the other bu
