On Tue, 04 Jul 2006, Tom Lane wrote:
> Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> > So why estimate regex expressions if there is no estimation possible?
> > Let's set this estimate to be pessimistic (match everything or
> > everything not null) and it will choose better plans.
>
> Better pla
Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> So why estimate regex expressions if there is no estimation possible?
> Let's set this estimate to be pessimistic (match everything or
> everything not null) and it will choose better plans.
Better plans for this specific example, worse plans for othe
On Tue, Jul 04, 2006 at 04:44:08PM +0200, Tomasz Ostrowski wrote:
> On Tue, 04 Jul 2006, Tom Lane wrote:
>
> > I think the real problem here is that regex matching is the wrong
> > tool for the job. Have you looked into a full-text index
> > (tsearch2)?
>
> So much to do with so little time...
On Tue, 04 Jul 2006, Tom Lane wrote:
> I think the real problem here is that regex matching is the wrong
> tool for the job. Have you looked into a full-text index
> (tsearch2)?
So much to do with so little time...
I've briefly looked into it but:
- it's complicated;
- it is not needed - basi
Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> I think because there is no good solution to this - no statistical
> information is going to predict how much data will match a regular
> expression.
Well, it's certainly hard to imagine simple stats that would let the
code guess that, say, "warsa" an
On Mon, 03 Jul 2006, Tom Lane wrote:
> > -> Seq Scan on organization (cost=0.00..480.95 rows=1 width=4) (actual
> > time=0.071..69.702 rows=1892 loops=1)
> > Filter: ((organization_location)::text ~* 'warszawa'::text)
>
> How many rows are there in the organization table?
About 9000. And
On Mon, 2006-07-03 at 22:31 +0200, Tomasz Ostrowski wrote:
> I have a very slow query when enable_seqscan=on and very fast when
> enable_seqscan=off. My schema looks like this (relevant columns
> only):
> PS. Actual table and column names are different (they're in Polish)
> but I've translated them
Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> I have a very slow query when enable_seqscan=on and very fast when
> enable_seqscan=off.
Here's your problem:
> -> Seq Scan on organization (cost=0.00..480.95 rows=1 width=4)
> (actual time=0.071..69.702 rows=1892 loops=1)
>
I have a very slow query when enable_seqscan=on and very fast when
enable_seqscan=off. My schema looks like this (relevant columns
only):
create table organizations (
organization_id serial primary key,
organization varchar(200) not null,
organization_location varchar(55) n
