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 wrote:
> On Thu, Sep 09, 2010 at 11:16:36AM -0400, Tom Lane w
On Thu, Sep 09, 2010 at 11:16:36AM -0400, Tom Lane wrote:
> Henk van Lingen 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,
Henk van Lingen 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 you need
On Thu, Sep 09, 2010 at 10:50:52AM -0400, Tom Lane wrote:
> Henk van Lingen 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'::reg
Henk van Lingen 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) @@
> to_tsquery('131.211.112.9'::text))
Well, the
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,
On Tue, Sep 7, 2010 at 8:48 AM, Henk van Lingen 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 and one IO
bound on
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 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 t
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 100
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'
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
