Perhaps one other interesting observation; when I earlier removed the status
check for which the rows got so wrongly estimated, the query got
dramatically faster. However, once I also remove all redundant checks the
query gets slower again.
This is the query with both status and redundant chec
Tom,
Thank you very much for your suggestions.
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
>
> Have you checked to make sure the query plans are reasonable?
I've attached the main query and its explain plan. I can't find a way to
improve it.
Does it make any diff
Harald Armin Massa wrote:
Carlos,
about your feature proposal: as I learned, nearly all
Perfomance.Configuration can be done by editing the .INI file and
making the Postmaster re-read it.
So, WHY at all should those parameters be guessed at the installation
of the database? Would'nt it be a
On Fri, Apr 27, 2007 at 07:23:41PM +0930, Shane Ambler wrote:
I would think that as you are sitting and watching the cpu usage, your
query would seem to taking a while to run, leading me to wonder if you are
getting a full table scan that is causing pg to wait for disk response?
If so, you pro
Jonah,
Um, shared_buffers is one of the most important initial parameters to
set and it most certainly cannot be set after startup.
Not after startup, correct. But after installation. It is possible to change
PostgreSQL.conf (not ini, to much windows on my side, sorry) and restart
postmaster.
On 4/28/07, Harald Armin Massa <[EMAIL PROTECTED]> wrote:
about your feature proposal: as I learned, nearly all
Perfomance.Configuration can be done by editing the .INI file and making the
Postmaster re-read it.
Um, shared_buffers is one of the most important initial parameters to
set and it mo
Well, that's darn odd. It should not be getting that so far wrong.
I've been puzzling on this for over a week now, but can't seem to find a
solution. Would you have some more hints of what I could possibly try next?
As far as I can see, the mentioned status column is just a simple column. Or
Carlos,
about your feature proposal: as I learned, nearly all
Perfomance.Configuration can be done by editing the .INI file and making the
Postmaster re-read it.
So, WHY at all should those parameters be guessed at the installation of the
database? Would'nt it be a saver point of time to have so
