We use it in contrib/intarray for set operations and contrib/tsearch2 for
full text search. The problem is how to store it to provide efficient
operations. We use RD-tree as a storage.
Oleg
On Sat, 28 May 2005, Gregory Maxwell wrote:
Has any thought been given to adding bloom filter i
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> In general, code snippet like this:
> if (hash_search(..., HASH_ENTER, ...) == NULL)
> action_except_elog__ERROR__;
> are considered unsafe if: (1) the allocation method of the target hash table
> could elog(ERROR) themselves and (2) the reaction
Tom Lane wrote:
> Bruce Momjian writes:
> > Here is an updated version of the COPY \x patch. It is the first patch
> > attached.
> > Also, I realized that if we support \x in COPY, we should also support
> > \x in strings to the backend. This is the second patch.
>
> Do we really want to do any
I have just noticed that this patch:
* Implements a hash-table cache of loaded tables, so we don't have
to read and parse the TZ file everytime we change a timezone. While
not necesasry now (we don't change timezones very often), I beleive
this will be neces
Has any thought been given to adding bloom filter indexes to PostgreSQL?
A bloom index would be created on a column, and could then be used to
accelerate exact matches where it is common that the user may query
for a value that doesn't exist. For example, with the query select
userid from user_tab
Has any thought been given to adding bloom filter indexes to PostgreSQL?
A bloom index would be created on a column, and could then be used to
accelerate exact matches where it is common that the user may query
for a value that doesn't exist. For example, with the query select
userid from user_tab
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Consider the senario like this:
> Backends register some dirty segments in BgWriterShmem->requests; bgwrite
> will AbsorbFsyncRequests() asynchornously but failed to record some one in
> pendingOpsTable due to an "out of memory" error. All dirty segmen
On 28 May 2005 10:25:48 -0400, Greg Stark <[EMAIL PROTECTED]> wrote:
>
> Jaime Casanova <[EMAIL PROTECTED]> writes:
>
> > The only problem i have found until now is that
> > update v_foo set col1 = DEFAULT; execute nextval twice per every record.
> > so there will be a gasp between numbers, but A
On 5/28/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Jaime Casanova <[EMAIL PROTECTED]> writes:
> > create rule ins_rule as on insert to v_foo do instead
> > insert into foo(col1, col2) values (new.col1, new.col2);
>
> > insert into v_foo(col2) values (1);
>
> > this give an error like:
> > psql:f:/
Jaime Casanova <[EMAIL PROTECTED]> writes:
> create rule ins_rule as on insert to v_foo do instead
> insert into foo(col1, col2) values (new.col1, new.col2);
> insert into v_foo(col2) values (1);
> this give an error like:
> psql:f:/views.sql:13: ERROR: null value in column "col1" violates
> not
Jaime Casanova <[EMAIL PROTECTED]> writes:
> The only problem i have found until now is that
> update v_foo set col1 = DEFAULT; execute nextval twice per every record.
> so there will be a gasp between numbers, but AFAIK nextval has no guarantee
> of returning sequential numbers.
While there's n
On 5/28/05, Tom Lane wrote:
>
> I think they may have intended to treat each time interval
> as the half-open interval [S,T), that is S <= time < T. However
> that would leave a zero-length interval as completely empty and
> thereby arguably not overlapping anything ... which they didn't
> make i
Hi, here we go again...
As you know there is a problem executing something like:
create table foo (
col1 serial,
col2 int
);
create view v_foo as select * from foo;
create rule ins_rule as on insert to v_foo do instead
insert into foo(col1, col2) values (new.col1, new.col2);
insert int
13 matches
Mail list logo
