--- 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.
Please
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
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
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
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
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:
snip
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.*'
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
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 early.
--- 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;
--- Martijn van Oosterhout kleptog@svana.org 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;
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 enough,
On Fri, Feb 24, 2006 at 09:44:37AM -0800, CG wrote:
--- Martijn van Oosterhout kleptog@svana.org 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
12 matches
Mail list logo
