I'm wondering how I can store word-level bigrams/trigrams in a tsvector
that I can query against. I was expecting the final query to match "the
air" and return the one tuple to me.
For instance:
postgres=# create table docs (a tsvector);
CREATE TABLE
postgres=# insert into docs (a) values (strip(
On Mon, Jul 20, 2009 at 12:29 PM, Greg Stark wrote:
> On Mon, Jul 20, 2009 at 7:40 PM, Alan Li wrote:
> > Attached is an updated patch that removes the O(n^2) behavior and the
> > awkwardness of optimizing the seqscan path as the plan was about to be
> > created. Now
On Sat, Jul 18, 2009 at 12:04 PM, Greg Stark wrote:
> On Sat, Jul 18, 2009 at 6:35 PM, Alan Li wrote:
> > Yeah, are you running into the same issue as well? I tried to figure out
> a
> > way around the O(n^2) behavior, but there were no existing direct
> > relationship b
On Sat, Jul 18, 2009 at 3:13 AM, Greg Stark wrote:
> This part:
>
> ! /* only try to optimize children rel's */
> ! foreach (lc, root->append_rel_list)
> ! {
> ! AppendRelInfo *a = (AppendRelInfo *) lfirst(lc);
> !
> !
On Fri, Jul 17, 2009 at 2:45 PM, Greg Stark wrote:
> Neat! I haven't read the patch yet but I have some questions.
>
> Does this handle the case where some partitions have an index and
> others don't? Ie. Does it just apply the regular optimization to each
> partition and then slap on the aggrega
Consider the following schema:
create table foo_archive (a int, b timestamp);
create index foo_archive_idx on foo_archive(b);
CREATE TABLE foo_archive_2007_01_01 (CONSTRAINT
foo_archive_2007_01_01_b_check CHECK (((b >= '2007-01-01'::date) AND (b <
'2007-01-02'::date INHERITS (foo_a
On Mon, Jun 22, 2009 at 7:16 AM, Tom Lane wrote:
> Alan Li writes:
> > How much concern is there for the contention for use cases where the WAL
> > can't be bypassed?
>
> If you mean "is something going to be done about it in 8.4", the
> answer is "n
Hi Tom,
How much concern is there for the contention for use cases where the WAL
can't be bypassed?
Thanks, Alan
On Sun, Jun 21, 2009 at 10:00 AM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
> > The following copying 3M rows(each) into a seperate table of the same
> > database.
>
> Is this
It doesn't look like it's related to autovacuum. I re-ran the test against
the two solaris boxes with autovacuum turned off and the results look about
the same.
8.3.7 - Solaris 10 11/06 s10x_u3wos_10 X86
real0m43.662s
user0m0.001s
sys 0m0.003s
real0m43.565s
user0m0.001s
sys
Hello,
I have multiple files with that have very similar distributions and I'm
seeing contention when concurrent COPY's are happening against a table with
a b-tree index on the timestamp column. Each file look something like the
following:
~4M rows with timestamp1
~4M rows with timestamp2
...
T
Running the following against HEAD and REL8_3_6:
create table foo (a varchar(500));
create view bar as select case foo.a when '1' then 'foo' else 'bar' end as
fa from foo;
\d bar
Causes as assertion in the backend:
TRAP: FailedAssertion("!(Node*)(((list_head(((OpExpr *)
w)->args))->data.ptr_
Attached are patches to fix the following compiler warnings that I see when
using gcc 4.3.2.
MASTER warning:
tablecmds.c: In function 'DropErrorMsgWrongType':
tablecmds.c:601: warning: format not a string literal and no format
arguments
REL8_3_STABLE warnings:
utility.c: In function 'DropErrorMsg
12 matches
Mail list logo
