Sushant,
the problem of phrase search not in implementation, but in the theoretical
basis. tsearch is query rich and phrase search should support all query
operations, so we need algebra for query operations. We need more time
to investigate this problem, but just have no spare time for this.
If
[EMAIL PROTECTED] (Markus Wanner) writes:
Hello Chris,
chris wrote:
Slony-I does the same, with the variation that it permits the option
of using a candidate primary key, namely an index that is unique+NOT
NULL.
If it is possible to support that broader notion, that might make
addition of
Here's a WIP patch implementing an oprrest function for tsvector @@
tsquery and tsquery @@ tsvector.
The idea is (quoting a comment)
/*
* Traverse the tsquery preorder, calculating selectivity as:
*
* selec(left_oper) * selec(right_oper) in AND nodes,
*
* selec(left_oper) +
Tom Lane wrote:
The bad news is that if you only do that, only the arch that you
actually build on will work. We have configure set up to insert
various hardware-dependent definitions into pg_config.h and
ecpg_config.h, and if you don't have the right values visible for
each compilation, the
Jan Urbański wrote:
The idea is (quoting a comment)
/*
* Traverse the tsquery preorder, calculating selectivity as:
Ekhm.
This should of course read postorder...
--
Jan Urbanski
GPG key ID: E583D7D2
ouden estin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi,
chris wrote:
I agree with you that tables are *supposed* to have primary keys;
that's proper design, and if tables are missing them, then something
is definitely broken.
Ah, I see, so you are not concerned about tables with a PRIMARY KEY for
which one wants another REPLICATION KEY, but
Hi,
chris wrote:
You may want to have a chat with Jan; he's got some thoughts on a more
general purpose mechanism that would be good for this as well as for
(we think) extremely efficient bulk data loading.
Jan, mind to share your thoughts? What use cases for such a general
purpose mechanism
Adriaan van Os [EMAIL PROTECTED] writes:
Tom Lane wrote:
You can get around that by hacking up the generated config files
with #ifdef __i386__ and so on to expose the correct values of
the hardware-dependent symbols to each build. Of course you have
to know what the correct values are --- if
Tom Lane wrote:
You can get around that by hacking up the generated config files
with #ifdef __i386__ and so on to expose the correct values of
the hardware-dependent symbols to each build. Of course you have
to know what the correct values are --- if you don't have a sample
of each
Am Thursday, 17. July 2008 schrieb Bruce Momjian:
Anyways the thing that struck me as odd was the messages appearing
*before* the header. It seems to me the header should print followed by
.psqlrc output followed by normal output.
Do you like this better?
$ psql test
psql
Am Saturday, 19. July 2008 schrieb Tom Lane:
The bad news is that if you only do that, only the arch that you
actually build on will work. We have configure set up to insert
various hardware-dependent definitions into pg_config.h and
ecpg_config.h, and if you don't have the right values
Markus Wanner wrote:
(Although, I'm still less than thrilled about the internal storage
format of these tuple collections. That can certainly be improved and
simplified.)
Care to expand more on what it is? On Replicator we're using the binary
send/recv routines to transmit tuples.
Peter Eisentraut [EMAIL PROTECTED] writes:
I'd imagine a related problem are the run tests in configure. They will
produce results for the platform that you run configure on. More properly,
you should run configure in cross-compilation mode (twice, and then merge the
output, as previously
13 matches
Mail list logo
