--- Bernhard Weisshuhn <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 27, 2006 at 10:27:20AM -0800, CG <[EMAIL PROTECTED]> wrote:
>
> > [...] I'd need to see if the space required for the varchar+btree tables
> are
> > comparible, better, or worse than the ltree+gist tables with regards to
> size.
>
On Mon, Feb 27, 2006 at 10:27:20AM -0800, CG <[EMAIL PROTECTED]> wrote:
> [...] I'd need to see if the space required for the varchar+btree tables are
> comparible, better, or worse than the ltree+gist tables with regards to size.
Please test this, I'm guessing (hoping actually) that having bazil
That would do the job, wouldn't it? :)
I don't think it's a naive question at all. Its quite a good question, and the
solution you suggest is a good option to have, and would probably work better
than the single-vector ltree index for simple substring matching. In my case,
the ltree+gist index ta
On Mon, Feb 27, 2006 at 09:14:40AM -0800, CG <[EMAIL PROTECTED]> wrote:
> I could probably get even better performance out of the table, at the cost of
> a
> significant increase in table and index size, by chopping up the columns into
> smaller chunks.
>
> "Hello World" would yield
>
> 'h.e.l.
Tsearch2 searches for whole words, and is designed with language in mind, yes?
I'm looking for consecutive characters in words or serial numbers, etc.
As for support, the same guys who wrote Tsearch2 wrote ltree. Can't go wrong
there!
Here's the solution to this problem: As usual, operator err
On Fri, Feb 24, 2006 at 09:02:04AM -0800, CG wrote:
> I have a search table which I use for partial-match text searches:
> For a string "Hello World" the ltree is created like 'h.e.l.l.o.w.o.r.l.d' ...
> If I wanted to find all rows with "orl" in them i would construct an lquery
> like '*.o.r.l.*'
On Fri, Feb 24, 2006 at 09:44:37AM -0800, CG wrote:
>
>
> --- Martijn van Oosterhout wrote:
>
> > That's very odd. Like the other person said, do you vacuum and analyse?
> > But my question is: is it using the index? What does EXPLAIN / EXPLAIN
> > ANALYZE tell you?
>
> data=# explain select *
CG <[EMAIL PROTECTED]> writes:
> INFO: index "search_vector_idx" now contains 1344672 row versions in 47725
> pages
> INFO: "letter_search": found 9 removable, 1344661 nonremovable row versions
> in 33984 pages
Yikes ... the index is bigger than the table! Seems like you've not
been vacuuming
--- Martijn van Oosterhout wrote:
> That's very odd. Like the other person said, do you vacuum and analyse?
> But my question is: is it using the index? What does EXPLAIN / EXPLAIN
> ANALYZE tell you?
data=# explain select * from search where search_vector ~ '*.o.r.l.*'::lquery;
--- Scott Marlowe <[EMAIL PROTECTED]> wrote:
> Are you vacuuming regularly, are your fsm settings high enough, and what
> does vacuum verbose say?
Autovacuum is running, but I do a nightly vacuum analyze. When I just do a
vacuum analyze on the table I get:
data=# vacuum analyze verbose search;
I
On Fri, Feb 24, 2006 at 09:02:04AM -0800, CG wrote:
> PostgreSQL 8.1.3
>
> I'm trying to collect some hard numbers to show just how much it degrades and
> over how long a time interval.
>
> All I have now is anecdotal evidence, and I was hoping to save myself some
> downtime by seeking advice ear
PostgreSQL 8.1.3
I'm trying to collect some hard numbers to show just how much it degrades and
over how long a time interval.
All I have now is anecdotal evidence, and I was hoping to save myself some
downtime by seeking advice early.
I have a search table which I use for partial-match text sear
12 matches
Mail list logo
