>> Why the procedure is not getting the performance advantage of Vacuum
>> analyse?
>Plan caching by the function, probably. Try disconnecting the session
>and reconnecting to prove the hypothesis.
>If it is a recurring problem for you, you could put the SELECT under
>EXECUTE in the function.
Anoo Sivadasan Pillai wrote:
> Why the procedure is not getting the performance advantage of Vacuum
> analyse?
Plan caching by the function, probably. Try disconnecting the session
and reconnecting to prove the hypothesis.
If it is a recurring problem for you, you could put the SELECT under
E
Hi All,
I have a procedure which contains only one Select statement. The
procedure take more time than expected to complete, the select statement
inside the procedure was taking about 2 minutes to complete.
After running a Vacuum Analyze on the underlying tables the select
statement could
"John Smith" <[EMAIL PROTECTED]> writes:
>> It's pipelined either way. But int8 is a pass-by-reference data type,
>> and it sounds like we have a memory leak for this case.
> Thanks for your reply. How easy is it to fix this? Which portion of
> the code should we look to change?
I was just looki
> > Interestingly though, when the range in the generate_series() was
> > small enough to fit in 4 bytes of memory (e.g.
> > generate_series(1,10) ), the above query completed consuming
> > only negligible amount of memory. So, it looked like the aggregate
> > computation was being pipeline
"John Smith" <[EMAIL PROTECTED]> writes:
> Consider the following query:
> postgres=# select count(*) from
> generate_series(1,10);
> A vmstat while this query was running seems to suggest that the
> generate_series() was being materialized to disk first and then the
> cou
My set-up:
Postgres 8.2.5 on AMD x86_64 compiled with GCC 3.4.4 on Gentoo Linux 2.6.17
4 GB of RAM,
shared_buffers = 1000
work_mem = 1024
This is regarding performance of set-returning functions in queries. I
use generate_series() in the following as an example. The true
motivation is a need fo
"Guillaume Pungeot" <[EMAIL PROTECTED]> writes:
> I assume that each postgresql process manage its own cache but that there is
> no global cache. Am I right ?
No, you aren't.
Are you sure you're not shutting down the postmaster? Just exiting
individual sessions shouldn't result in anything getti
Hello,
I have a problem with my install of postgresql. I have a program that
requests DB by opening persistent connexions. When the program is launched,
the disk IO are very high until postgresql cache is good enough (a few
hours). The problem is that when I stop the program all the connexions are
Jakub Ouhrabka <[EMAIL PROTECTED]> writes:
> Yes, I can confirm that it's triggered by SIGUSR1 signals.
OK, that confirms the theory that it's sinval-queue contention.
> If I understand it correctly we have following choices now:
> 1) Use only 2 cores (out of 8 cores)
> 2) Lower the number of i
> You could check this theory
> out by strace'ing some of the idle backends and seeing if their
> activity spikes are triggered by receipt of SIGUSR1 signals.
Yes, I can confirm that it's triggered by SIGUSR1 signals.
If I understand it correctly we have following choices now:
1) Use only 2 cor
11 matches
Mail list logo
