Re: [GENERAL] Adding Arabic dictionary for TSearch2.. to_tsvector('arabic'...) doesn't work..
Mohamed wrote: Thank you for you detailed answer. I have learned alot more about this stuff now :) Your welcome :-) As I see it accordingly to the results it's between Hunspell and Aspell. My Aspell version is 0.6 released 2006. The Hunspell was released in 2008. When I run the Postgres command \dFt I get the following list : * ispell * simple * snowball * synonym * thesaurus So I set up my dictionary with the ispell as a template and Hunspell/Aspell files. Now I just have one decision to make :) Just another thing: If you want to support multiple language dictionaries for a single table, with each row associated to its own dictionary Not really, since the two languages don't overlap, couldn't I set up two separate dictionaries and index against both on the whole table ? I think that's what Oleg was refering to. Not sure... Neither am I, so when in doubt, try it out. And let us know the results. Thanks for all the help / Moe Ps. I can't read Arabic so I can't have a look on the files to decide :O In which case, assuming you do not have access to a friend who is able to read Arabic, either choose the file with the most entries (making assumption that more is better) or take the one that came with the dictionary (assuming that those two will be best matched) or if you still can't decide, flip a coin. As you can't read Arabic, it is not as if you are in a position to put both files through their paces and test them against a word list, picking the one that gives you the best results for the type of words your text is likely to contain. Cheers, Andy
[GENERAL] Question about updates and MVCC
Hello, I have a couple of questions regarding how MVCC (in postges 8.3.3 if it makes a difference) affects vacuum. #1. If I am doing an update to a row and none of the values have changed, will that cause a "hole" that requires vacuum to reclaim? #2. I have a column in my table (called "status", if you can believe *that*). This contains 1 of 4 values: -1: row is expired, but needs to be marked deleted from index 0: row is expired, and has been indexed 1: row is active, and has been indexed 2: row is new or updated, and needs to be indexed .. The point of all this is that when a new row is added, or updated, it goes into a status = 2, so the process that comes along later to build search indexes, can quickly query any listings in status = 2 and incrementally update the index. (Same with respect to status -1, except those rows are no longer active and need to be deleted from the index)... The issue with this is that it seems to be causing a lot of vacuum work The total number of rows in the table are about 30 million, but partitioned into about 130 segments, based on a category... I'm trying to minimize the amount of vacuum work because not much else changes in the table over time, but the status column will get fiddled with 4 times during the life of a row... Thanks, as always! - Greg -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Rename a constraint
I can't find anything in the documentation, but does anyone know if there is a way to rename a constraint? Thanks Thom
Re: [GENERAL] Rename a constraint
On 10/01/2009 19:15, Thom Brown wrote: > I can't find anything in the documentation, but does anyone know if > there is a way to rename a constraint? I just tried it with a primary key... test=# alter table t1 alter constraint t1_pk rename to t1_pp; ERROR: syntax error at or near "constraint" LINE 1: alter constraint t1_pk rename to t1_pp; ... and as you can see it didn't work. I suppose you could always drop and recreate it with a different name. Ray. -- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland r...@iol.ie Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals -- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Rename a constraint
That would make more sense wouldn't it. :) Yeah, I think that's the answer. Cheers! Thom 2009/1/10 Raymond O'Donnell > On 10/01/2009 19:15, Thom Brown wrote: > > I can't find anything in the documentation, but does anyone know if > > there is a way to rename a constraint? > > I just tried it with a primary key... > > test=# alter table t1 alter constraint t1_pk rename to t1_pp; > ERROR: syntax error at or near "constraint" > LINE 1: alter constraint t1_pk rename to t1_pp; > > > ... and as you can see it didn't work. I suppose you could always drop > and recreate it with a different name. > > Ray. > > > -- > Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland > r...@iol.ie > Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals > -- >
[GENERAL] Renaming tables and columns to lowercase
Hello, In a migration process, I've imported a bunch of tables from an old Access database to PostgreSQL. The name of tables and fields on the source are mixed case. When copying tables to pg via ODBC, identifiers are copied in mixed case into pg destination db. Data is copied without any problem. Due to pg folding policies, I always need to quote my identifiers when querying data on these tables. It's something overkill in typing and time. --> Can I rename all tables and columns to lowercase, in a specified schema? Thanks Bruno Lavoie -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Renaming tables and columns to lowercase
On Sat, 2009-01-10 at 17:25 -0500, Bruno Lavoie wrote: > Hello, > > In a migration process, I've imported a bunch of tables from an old > Access database to PostgreSQL. The name of tables and fields on the > source are mixed case. When copying tables to pg via ODBC, identifiers > are copied in mixed case into pg destination db. Data is copied without > any problem. > > Due to pg folding policies, I always need to quote my identifiers when > querying data on these tables. It's something overkill in typing and time. > > --> Can I rename all tables and columns to lowercase, in a specified schema? Sure. Do this :) \o /tmp/go_to_lower select 'ALTER TABLE '||'"'||tablename||'"'||' RENAME TO ' || lower(tablename)||';' from pg_tables where schemaname = 'public'; psql -U username database < /tmp/go_to_lower Sincerely, Joshua D. Drake -- PostgreSQL Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] compile of 8.1.15
I have been trying to install 8.1.14 and 15 and it seems like there is an infinite loop in the make file. I do not have the skills to find it. Has anyone else had success compiling for Linux with gmake? Thanks. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] compile of 8.1.15
Chuck Davis wrote: > I have been trying to install 8.1.14 and 15 and it seems like there is > an infinite loop in the make file. I do not have the skills to find > it. Has anyone else had success compiling for Linux with gmake? We certainly used to be able to compile it on every Linux available at the time. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] compile of 8.1.15
"Chuck Davis" writes: > I have been trying to install 8.1.14 and 15 and it seems like there is > an infinite loop in the make file. I do not have the skills to find > it. Has anyone else had success compiling for Linux with gmake? I'll bet lunch your system clock is far in the past (ie, before the mod date of the source files). regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
