this month.
http://www.postgresql-archive.org/OLAP-reporting-queries-fall-into-nested-loops-over-seq-scans-or-other-horrible-planner-choices-tp5990160.html
where this has been discussed in some length.
regards,
-Gunther
_page_cost
(noticing that it has a SSD or HDD) and it should see how much disk read
is from cache and how much goes out to disk. Why isn't the executor of
queries the best person to ask for these cost constants?
regards,
-Gunther
--
Sent via pgsql-performance mailing list (pgsql-performan
special privileges.
But until that is done, please put in the pg_hint_plan.c. Hints don't
hurt. If you don't like them, don't use them.,
regards,
-Gunther
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www
gured out: by all means include the
pg_hint_plan.c -- pretty please!
regards,
-Gunther
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
extremely efficient with XSLT for complex intelligent algorithms, and I
dream of a PgSQL query plan structure exposed as XML which an XSLT
plugin could then process to edit the plan. People could experiment with
awesome intelligent new strategies based on statistics gathered along
the way of the
am
extremely efficient with XSLT for complex intelligent algorithms, and I
dream of a PgSQL query plan structure exposed as XML which an XSLT
plugin could then process to edit the plan. People could experiment with
awesome intelligent new strategies based on statistics gathered along
the way of
Hi, this is Gunther, have been with PgSQL for decades, on an off this
list. Haven't been on for a long time making my way just fine. But there
is one thing that keeps bothering me both with Oracle and PgSQL. And
that is the preference for Nested Loops.
Over the years the archives
Pavan Deolasee wrote:
On Thu, Apr 17, 2008 at 2:57 PM, Gunther Mayer
<[EMAIL PROTECTED]> wrote:
You see, all updates change most of the data fields but never ever touch
the time field. Assuming correct and efficient behaviour of postgresql it
should then also never touch the time ind
time index and incur zero overhead
in its presence, but is this really the case? If it somehow does update
the index too even though the value hasn't changed by some weird
implementation detail I'd rather not have that index and live with slow
queries for the few times a day that repor
Kristo Kaiv wrote:
could be that the checkpoints are done too seldom.
what is your wal checkpoint config?
wal checkpoint config is on pg defaults everywhere, all relevant config
options are commented out. I'm no expert in wal stuff but I don't see
how that could cause the problem?
Scott Marlowe wrote:
Gunther Mayer wrote:
Hi there,
We run a small ISP with a FreeBSD/freeradius/postgresql 8.2.4 backend
and 200+ users. Authentication happens via UAM/hotspot and I see a lot
of authorisation and accounting packets that are handled via PL/PGSQL
functions directly in the
Andrew Sullivan wrote:
On Wed, Jun 06, 2007 at 09:20:54PM +0200, Gunther Mayer wrote:
What the heck could cause such erratic behaviour? I suspect some type of
resource problem but what and how could I dig deeper?
Is something (perhaps implicitly) locking the table? That will cause
ven get hit. Finally, the problem seems unrelated to load
because it happens at 4am just as likely as at peak traffic time.
What the heck could cause such erratic behaviour? I suspect some type of
resource problem but what and how could I dig deeper?
Gunther
---
13 matches
Mail list logo
