Hi there,
there is a chinese parser for tsearch2 available from
http://code.google.com/p/nlpbamboo/wiki/TSearch2 under BSD license.
It'd be nice to have it for chinese text search configuration we are currently
completely missing, as well as for japanese language ( any guess ?)
Joshua D. Drake [EMAIL PROTECTED] schrieb:
salman Sheikh wrote:
Hi freinds,
i wanted to add my all tables once in MFC application,
i have a databank,which has 11 tables and i want to add them all togather.
After Adding all tables, it shows me always this errors by debugging.
ERROR:
Kevin Galligan wrote, On 29-10-08 23:35:
An example of a slow query is...
select count(*) from bigdatatable where age between 22 and 40 and state
= 'NY';
explain analyze returned the following...
Aggregate (cost=5179639.55..5179639.56 rows=1 width=0) (actual
time=389529.895..389529.897
Hi..
I've this problem in installation...I installed the postgresql-8.3
version without the service...Then to initialize I gave the command
initdb -D path\ in the command prompt...It showed some notifications
and it finally said to start the database server I needed to enter the
command
Gregory Stark wrote, On 01-11-08 14:02:
Ivan Sergio Borgonovo [EMAIL PROTECTED] writes:
But sorry I still can't get WHY compression as a whole and data
integrity are mutually exclusive.
...
[snip performance theory]
Postgres *guarantees* that as long as everything else works correctly it
Grzegorz Jaśkiewicz wrote, On 30-10-08 12:13:
it should, every book on encryption says, that if you compress your data
before encryption - its better.
Those books also should mention that you should leave this subject to
experts and have numerous examples on systems that follow the book,
I am attempting to move an unusually large legacy database from old DBF
files into a Postgres database. I've been able to clean up the DBF
tables, export them to CSV and convert that CSV into a SQL batch file.
My batch file contains 10 million INSERT queries to populate the
corresponding table
On Sun, Nov 02, 2008 at 02:13:34PM -0600, Milarsky, Jeremy F. wrote:
I am attempting to move an unusually large legacy database from old DBF
files into a Postgres database. I've been able to clean up the DBF
tables, export them to CSV and convert that CSV into a SQL batch file.
snip
At a wild
On 02/11/2008 19:15, Shashank Mujumdar wrote:
C:\Program Files\PostgreSQL\8.3\bin postgres -D C:\path\to\pgsqldata
when I entered the command I got the following notification..
LOG: database system was shut down at 2008-11-02 18:17:13 IST
LOG: database system is ready to accept
/*--
Bienvenidos a:
PGDay 2008 Rio de la Plata
Organizado por la comunidad de PostgreSQL de Bs As (BaPUG)
Web: www.postgres-arg.org
On 02/11/2008 19:15, Shashank Mujumdar wrote:
After this nothing happens..The command prompt does not appear..As if
the cursor is waiting for some input or something like that..
Please let me know if I missed something in installation process..What
might be the problem ???
I meant to add
Hello everyone,
I am new to the forum and fairly new to databases (particularly PostgreSQL).
I have done some searching on the internet and can't really get a hold of an
answer to my question. So here it goes:
I am working on a Customer Purchasing-based project where I must use a
database with
Joris Dobbelsteen wrote:
Also I still have to see an compression algorithm that can sustain over
(or even anything close to, for that matter) 100MB/s on todays COTS
hardware. As TOAST provides compression, maybe that data can be
transmitted in compressed manner (without recompression).
I
Brian714 wrote:
Hello everyone,
I am new to the forum and fairly new to databases (particularly PostgreSQL).
I have done some searching on the internet and can't really get a hold of an
answer to my question. So here it goes:
I am working on a Customer Purchasing-based project where I must use
Hi
Generally, I have avoided using VIEWS within application code and only
used them for client interfaces, the sole reason being the performance
of views against tables.
Changes to database over the past few years appear to have improved the
performance of views, but I am still not
On Sun, Nov 2, 2008 at 4:11 PM, Simon Windsor
[EMAIL PROTECTED] wrote:
Hi
Generally, I have avoided using VIEWS within application code and only used
them for client interfaces, the sole reason being the performance of views
against tables.
Have you confirmed this belief with tests? Or just
On Sun, Nov 02, 2008 at 02:30:45PM -0800, Brian714 wrote:
I would like to convert the column that used to be
credit_card_number from the Customers table and turn it into a cc_id
which is an integer that references the column id from the table
Creditcards.
[...]
Does anyone know of a script
Am I right to avoid to VIEWS within application code?
How one uses views is more a matter of taste and best practices, than
a matter of rules like this. Frankly, this rule sounds rather ill
conceived.
My feeling is that views can be difficult to maintain when they are
nested, but otherwise use
On Mon, Nov 03, 2008 at 08:18:54AM +0900, Craig Ringer wrote:
Joris Dobbelsteen wrote:
Also I still have to see an compression algorithm that can sustain over
(or even anything close to, for that matter) 100MB/s on todays COTS
hardware. As TOAST provides compression, maybe that data can be
Sam Mason wrote:
On Mon, Nov 03, 2008 at 08:18:54AM +0900, Craig Ringer wrote:
Joris Dobbelsteen wrote:
Also I still have to see an compression algorithm that can sustain over
(or even anything close to, for that matter) 100MB/s on todays COTS
hardware. As TOAST provides compression, maybe
Milarsky, Jeremy F. wrote:
I have, for the record, attempting to get all 10 million rows in with a
single COPY command. This method has not been successful, apparently due
to client encoding (despite executing several different set
client_encoding in each attempt).
This is probably something
Craig Ringer [EMAIL PROTECTED] writes:
I get 19 Mbit/s from gzip (deflate) on my 2.4GHz Core 2 Duo laptop. With
lzop (LZO) the machine achieves 45 Mbit/s. In both cases only a single
core is used. With 7zip (LZMA) it only manages 3.1 Mb/s using BOTH cores
together.
It'd be interesting to know
Simon,
* Simon Windsor ([EMAIL PROTECTED]) wrote:
Generally, I have avoided using VIEWS within application code and only
used them for client interfaces, the sole reason being the performance
of views against tables.
Views really shouldn't have a large impact on overall performance. In
Tom Lane wrote:
Wire protocol compression support in PostgreSQL would probably still be
extremely useful for Internet or WAN based clients, though,
Use an ssh tunnel ... get compression *and* encryption, which you surely
should want on a WAN link.
An ssh tunnel, while very useful, is only
On Sun, Nov 2, 2008 at 6:39 PM, Stephen Frost [EMAIL PROTECTED] wrote:
Simon,
* Higher overhead mapping to original tables and indexes
This just plain isn't true in PG, at least, and I'd think most other
sensible databases..
Note that, at least in older versions, MySQL completely
On Mon, Nov 03, 2008 at 10:01:31AM +0900, Craig Ringer wrote:
Sam Mason wrote:
Your lzop numbers look *very* low; the paper suggests
compression going up to ~0.3GB/s on a 2GHz Opteron.
Er ... ENOCOFFEE? . s/Mb(it)?/MB/g . And I'm normally *so* careful about
Mb/MB etc; this was just a
Scott Marlowe [EMAIL PROTECTED] writes:
Note that, at least in older versions, MySQL completely materialized a
temporary table from a view, then used that for the view. This is
horribly inefficient, and results in a lot of people thinking views
are slow. Not sure if this has been addressed
We've been toying around with reworking our years old database schema and
replacing the old tables with updatable views into the new schema. The only
real problem we've had with it is that queries to one of our views seem to
be joining on unnecessary tables because the view does the join. We
On Sun, Nov 2, 2008 at 7:19 PM, Sam Mason [EMAIL PROTECTED] wrote:
On Mon, Nov 03, 2008 at 10:01:31AM +0900, Craig Ringer wrote:
So - it's potentially even worth compressing the wire protocol for use
on a 100 megabit LAN if a lightweight scheme like LZO can be used.
The problem is that then
does anyone know if postgres support 'refresh' of applicable index(es) of a
materialized view on refresh?
Thanks,
Martin
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business
of
On Sun, Nov 2, 2008 at 7:40 PM, Martin Gainty [EMAIL PROTECTED] wrote:
does anyone know if postgres support 'refresh' of applicable index(es) of a
materialized view on refresh?
Postgresql has no built in support for materialized views. If you
follow the excellent tutorial on how to make your
Gday,
I'm currently converting an MS Access database to PostgreSQL (version 8.1 as it
is the vesion that ships with CentOS 5).
I'm having trouble with an INSERT statement attempting to insert an empty value
('') into a field with data type DATE. This produces the following error
message:
Mike Hall wrote:
Gday,
I'm currently converting an MS Access database to PostgreSQL (version 8.1 as it
is the vesion that ships with CentOS 5).
I'm having trouble with an INSERT statement attempting to insert an empty value
('') into a field with data type DATE. This produces the following
am Mon, dem 03.11.2008, um 16:03:33 +0930 mailte Mike Hall folgendes:
Gday,
I'm currently converting an MS Access database to PostgreSQL (version 8.1 as
it is the vesion that ships with CentOS 5).
I'm having trouble with an INSERT statement attempting to insert an empty
value ('') into
34 matches
Mail list logo
