2015-05-25 16:28 GMT+02:00 Adrian Klaver :
> On 05/25/2015 07:17 AM, Piotr Gasidło wrote:
>> (...)
>> I've moved from Linux to FreeBSD. I've used uuid-ossp. Now I need to
>> aply patch to make it work under FreeBSD. This is rather dirty hack.
>> So I need to replace it once and for all with uuid-fr
Hi everybody,
the following stemming results made me curious:
select to_tsvector('german', 'systeme'); > 'system':1
select to_tsvector('german', 'systemes'); > 'system':1
select to_tsvector('german', 'systems'); > 'system':1
select to_tsvector('german', 'systemen'); > 'system':1
select to_tsvect
Sven R. Kunze wrote:
> the following stemming results made me curious:
>
> select to_tsvector('german', 'systeme'); > 'system':1
> select to_tsvector('german', 'systemes'); > 'system':1
> select to_tsvector('german', 'systems'); > 'system':1
> select to_tsvector('german', 'systemen'); > 'system':1
You can ask http://snowball.tartarus.org/ for stemmer. Meanwhile,
you can have small personal dictionary (before stemmer) with such
exceptions, for example, use synonym template
system system
Oleg
On Tue, May 26, 2015 at 11:18 AM, Sven R. Kunze
wrote:
> Hi everybody,
>
> the following stemmin
Thanks, Oleg. Unfortunately, that does not work quite well as German is
comprised of many compound nouns.
In fact, I discovered that anomaly by searching through a
domain-specific word table. For example: Waferhandlingsystem. There are
many '*system' but the PostgreSQL does not allow me to hav
Thanks Albe for that detailed answer.
On 26.05.2015 11:01, Albe Laurenz wrote:
Sven R. Kunze wrote:
the following stemming results made me curious:
select to_tsvector('german', 'systeme'); > 'system':1
select to_tsvector('german', 'systemes'); > 'system':1
select to_tsvector('german', 'systems
Sven R. Kunze wrote:
> However, are you sure, I am using snowball? Maybe, I am reading the
> documenation wrong:
test=> SELECT * FROM ts_debug('german', 'system');
alias | description | token | dictionaries | dictionary | lexemes
---+-++---+-
Thanks. It seems as if I have use snowball. So, I go ahead and post my
issue at github.
Maybe, I have difficulties to understand the relationship/dependencies
between all these 'maybe' available dictionary/parser/stemmer packages.
What happens if I install all packages for a single language?
For future reference: https://github.com/snowballstem/snowball/issues/19
On 26.05.2015 12:29, Sven R. Kunze wrote:
Thanks. It seems as if I have use snowball. So, I go ahead and post my
issue at github.
Maybe, I have difficulties to understand the relationship/dependencies
between all these
Sven R. Kunze wrote:
> Maybe, I have difficulties to understand the relationship/dependencies
> between all these 'maybe' available dictionary/parser/stemmer packages.
>
> What happens if I install all packages for a single language? (hunspell,
> myspell, ispell, snowball)
>
> Are they complement
have a read:
http://www.techrepublic.com/article/postgres-pushes-past-mysql-in-developer-hearts/
merlin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I think I understand now.
Thus, the issue at hand could (maybe) be solved by passing words first
to one of those more elaborate dictionaries (myspell, hunspell or
ispell) and if still necessary then to snowball.
Did I get this right?
On 26.05.2015 13:38, Albe Laurenz wrote:
Sven R. Kunze w
Sven R. Kunze wrote:
> I think I understand now.
>
> Thus, the issue at hand could (maybe) be solved by passing words first
> to one of those more elaborate dictionaries (myspell, hunspell or
> ispell) and if still necessary then to snowball.
>
> Did I get this right?
I have never experimented w
Melvin - thanks for sharing.
Here is the query I use which lists the percent of queries against the
table which use the index ordered by least used first.
The 'pg_relation_size(relid)>(5*8192)' is used to remove any tables that
would be so small the optimizer would just choose a table scan.
SELE
With Melvin's kind permission, I have created a repository on github which
has all of these files in it. Hopefully that will allow them to "stick
around" a bit longer. You can peruse them at:
https://github.com/JohnArchieMckown/PostgreSQL-DBA-tools
Also, this allows you to preview individual files
The query I previously sent was table level. Here is an index level one:
SELECT pg_stat_user_indexes.schemaname,
pg_stat_user_indexes.relname,
pg_stat_user_indexes.indexrelid,
pg_stat_user_indexes.indexrelname,
pg_stat_user_indexes.idx_scan,
pg_stat_user_tables.se
Will,
Much thanks. Let's keep up the sharing with the community.
On Tue, May 26, 2015 at 11:32 AM, William Dunn wrote:
> The query I previously sent was table level. Here is an index level one:
> SELECT pg_stat_user_indexes.schemaname,
>pg_stat_user_indexes.relname,
>pg_stat_use
On 05/25/2015 07:58 PM, Adrian Klaver wrote:
On 05/25/2015 01:41 PM, Francisco Reyes wrote:
I understood that is just a md5 hash of the password and the username
with the string md5 pre-appended, so it should be the same.
Mistery solved..
Because I usually do "script" of most of my work for aud
Hello,
I have a question about the query optimizer and its performance on spatial
datasets, specifically rasters. My use case is rather unique, the
application that I am developing allows users to request summarizations of
various geographic boundaries around the world. Therefore our raster
datase
Hello Laurenz,
Thanks for your feedback. Actually when I said that the same overhead
occurs in Oracle I was referring to bloat in the UNDO logs, which similar
to PostgreSQL dead tuples has some impact on size/performance and is the
majority of the trade-off considered when deciding to implement Fl
Hello, I'd like to postpone an "autovacuum: VACUUM public.mytable (to
prevent wraparound)" and handle it manually at another time. I thought I
could set these storage parameters on the large table in question
("mytable") like this:
ALTER TABLE mytable SET (
autovacuum_freeze_min_age=1000,
Steve Kehlet wrote:
> Hello, I'd like to postpone an "autovacuum: VACUUM public.mytable (to
> prevent wraparound)" and handle it manually at another time. I thought I
> could set these storage parameters on the large table in question
> ("mytable") like this:
>
> ALTER TABLE mytable SET (
> auto
Dear Andy,
We are using bulk collect to enhance the performance as the data is huge.
But as you said it is ideally insert into b select * from a;
So now I am using the looping through query result option as Adrian
suggested.
http://www.postgresql.org/docs/9.4/interactive/plpgsql-control-struct
23 matches
Mail list logo
