On Thu, Sep 09, 2010 at 11:16:36AM -0400, Tom Lane wrote:
Henk van Lingen h.g.k.vanlin...@uu.nl writes:
On Thu, Sep 09, 2010 at 10:50:52AM -0400, Tom Lane wrote:
Well, there's your problem: the planner is off by a factor of about 500
on its estimate of the number of rows matching
Maybe you can extract stuff like IP addresses and words like 'error'
and put it in a separate column in the table. Full text search is not
a solution for data that is in a wrong format.
On Fri, Sep 10, 2010 at 10:27 AM, Henk van Lingen h.g.k.vanlin...@uu.nl wrote:
On Thu, Sep 09, 2010 at
On Tue, Sep 07, 2010 at 07:26:25PM +0200, Alban Hertroys wrote:
Do you have output of explain analyse for these queries as well? It's
hard to see what is actually going on with just the explain - we can't
see which part of the query is more expensive than the planner
expected, for
Henk van Lingen h.g.k.vanlin...@uu.nl writes:
- Bitmap Heap Scan on systemevents (cost=61221.23..668806.93
rows=239805 width=158) (actual time=9.131..1786.406 rows=464 loops=1)
Recheck Cond: (to_tsvector('english'::regconfig, message) @@
On Thu, Sep 09, 2010 at 10:50:52AM -0400, Tom Lane wrote:
Henk van Lingen h.g.k.vanlin...@uu.nl writes:
- Bitmap Heap Scan on systemevents (cost=61221.23..668806.93
rows=239805 width=158) (actual time=9.131..1786.406 rows=464 loops=1)
Recheck Cond:
Henk van Lingen h.g.k.vanlin...@uu.nl writes:
On Thu, Sep 09, 2010 at 10:50:52AM -0400, Tom Lane wrote:
Well, there's your problem: the planner is off by a factor of about 500
on its estimate of the number of rows matching this query, and that's
what's causing it to pick the wrong plan. What
On Fri, Sep 03, 2010 at 09:20:39AM +0200, Yeb Havinga wrote:
If the index is useless anyway, you might consider dropping it.
Otherwise, increasing random_page_cost might help in choosing the
otherplan, but on the other hand that plan has index scanning too,
so I'm not to sure
Sorry for not replying earlier, I've been quite busy.
On 31 Aug 2010, at 16:50, Henk van Lingen wrote:
syslog=# \d systemevents
Table public.systemevents
Column |Type |
Modi
fiers
On Tue, Sep 7, 2010 at 8:48 AM, Henk van Lingen h.g.k.vanlin...@uu.nl wrote:
Thanks for your answer. Dropping the (pkey) index is not an option.
iostat suggest the thing is CPU bound (%iowait remaining 11% but cpu
rizing from 1 to 13 %)
How man cores that server have? If you've got 8 cores
Henk van Lingen wrote:
Now there are two types of query plans:
syslog=# explain SELECT id, devicereportedtime, facility, priority, fromhost, syslogtag, infounitid, message FROM systemevents WHERE ( ( to_tsvector('english', message) @@ to_tsquery ( '131.211.112.9')) ) ORDER BY id DESC LIMIT
No ideas on this one?
Regards,
On Tue, Aug 31, 2010 at 04:50:09PM +0200, Henk van Lingen wrote:
Hi,
I've the problem my database is not using the 'right' queryplan in all
cases. Is there a way I can force that and/or how should I tuned the
table statistics?
I'm doing
Hi,
I've the problem my database is not using the 'right' queryplan in all
cases. Is there a way I can force that and/or how should I tuned the
table statistics?
I'm doing a rsyslog database in PostgreSQL with millions of records
(firewall logging). The db scheme is the so called 'MonitorWare'
12 matches
Mail list logo
