On Thu, 5 Dec 2013, Andy Colson wrote:
On 12/5/2013 4:05 PM, Frank Miles wrote:
The table schema is {\d
credmisc}:
And this is all owned by: {\dp credmisc}
You have a table credmisc, in schema credmisc, owned by credmisc?
It could be a path problem. Maybe trigger should be:
Sorry for the
On Thu, 5 Dec 2013, Andy Colson wrote:
On 12/5/2013 4:05 PM, Frank Miles wrote:
[snip]
Table "public.credmisc"
Column | Type |Modifiers
--+--+-
On 12/5/2013 4:05 PM, Frank Miles wrote:
The table schema is {\d
credmisc}:
And this is all owned by: {\dp credmisc}
You have a table credmisc, in schema credmisc, owned by credmisc?
It could be a path problem. Maybe trigger should be:
trig_credmisc_updt BEFORE UPDATE ON credmisc.credmisc
On 12/5/2013 4:05 PM, Frank Miles wrote:
I'm in the process of moving from a server running postgresql-8.4
(Debian-oldstable)
to a newer machine running postgresql-9.3. The dumpall-restore process
seemed to
go perfectly. In running my self-test script, I discovered that one of
the tables
couldn
I'm in the process of moving from a server running postgresql-8.4
(Debian-oldstable)
to a newer machine running postgresql-9.3. The dumpall-restore process seemed
to
go perfectly. In running my self-test script, I discovered that one of the
tables
couldn't be cleared of some unit-test entries
Janek Sendrowski wrote:
> I already had a try with gist/gin-index-based trigramm search
> (pg_trgm extension), fulltextsearch (tsearch2 extension) and a
> pivot-based indexing (Fixed Query Array), but it's all to slow or
> not suitable.
When you tried tsearch2, did you use a trigger to store the
On 12/5/2013 12:46 AM, 吕晓旭 wrote:
We find so weird problem on our productive PostgreSQL system. And
I don't know how could I do to resolve this problem.
We deployed PostgreSQL 9.2.4 on two system environments, and the
performances between them are absolutely different. one of them it's
On 12/5/2013 11:29 AM, Giuseppe Broccolo wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Il 05/12/2013 17:16, Andy Colson ha scritto:
The docs say vacuum, but the param is vacuum_freeze_table_age, so
do I need to "vacuum freeze" all the tables, or is vacuum enough?
Also, will "set vacuu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Il 05/12/2013 17:16, Andy Colson ha scritto:
> The docs say vacuum, but the param is vacuum_freeze_table_age, so
> do I need to "vacuum freeze" all the tables, or is vacuum enough?
>
> Also, will "set vacuum_freeze_table_age = 0; vacuum freeze;" wo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Il 05/12/2013 17:16, Andy Colson ha scritto:
Setting vacuum_freeze_table_age to 0 forces VACUUM to always scan all
pages, effectively ignoring the visibility map. In this way a scan of
the whole table is done, ensuring all old XIDs are replaced by
The docs say vacuum, but the param is vacuum_freeze_table_age, so do I
need to "vacuum freeze" all the tables, or is vacuum enough?
Also, will "set vacuum_freeze_table_age = 0; vacuum freeze;" work, or do
I need to modify the postgresql.conf and reload?
-Andy
--
Sent via pgsql-general maili
Richard Dunks wrote:
> I will run this command 7 times with different daily table.
> [ ... ] a WHERE NOT EXISTS (SELECT * FROM upsert b WHERE a.firewall [ ... ]
>
> When I run the command I get an error
> ERROR: column reference "firewall" is ambiguous
> LINE 3: ... a WHERE NOT EXISTS (SELECT
Is khugepaged running during the stalls?
http://www.postgresql.org/message-id/20130716195834.8fe5c79249cb2ff0d4270...@yahoo.es
Matt
On Thu, Dec 5, 2013 at 7:44 AM, Scott Marlowe wrote:
> On Thu, Dec 5, 2013 at 1:46 AM, 吕晓旭 wrote:
>>
>>
>>
>> Hi, all
>> We find so weird problem on our produc
On Thu, Dec 5, 2013 at 1:46 AM, 吕晓旭 wrote:
>
>
>
> Hi, all
> We find so weird problem on our productive PostgreSQL system. And I don't
> know how could I do to resolve this problem.
> We deployed PostgreSQL 9.2.4 on two system environments, and the
> performances between them are absolu
On 5.12.2013 15:14, Tom Lane wrote:
> Ladislav Lenart writes:
>> What happens if I issue UPDATE SET FROM... but with incomplete/buggy WHERE
>> condition and thus SEVERAL rows from the from_list match ONE row to update?
>
> Any given row will be updated at most once. However, the from_list row
>
Ladislav Lenart writes:
> What happens if I issue UPDATE SET FROM... but with incomplete/buggy WHERE
> condition and thus SEVERAL rows from the from_list match ONE row to update?
Any given row will be updated at most once. However, the from_list row
it gets updated against will be unpredictable,
Hello.
What happens if I issue UPDATE SET FROM... but with incomplete/buggy WHERE
condition and thus SEVERAL rows from the from_list match ONE row to update?
Thank you in advance,
Ladislav Lenart
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your su
Thanks everyone for the reply. So I would conclude it as OpenVZ problem,
probably we will run some further check just to make sure no data
corruption.
Many thanks again :)
On Thu, Dec 5, 2013 at 12:23 AM, Kevin Grittner wrote:
> Albe Laurenz wrote:
> > Shuwn Yuan Tee wrote:
> >
> >> We recent
May be totally a bad idea :
explode your sentence into(sentence_number, one_word), n times , (makes a
big table, you may want to partition)
then, classic index on sentence number, and on the one world (btree if you
make = comparison , more subtel if you do "like 'word' ")
depending on perf, it cou
Hi,
I have tables with millions of sentences. Each row contains a sentence. It is
natural language and every language is possible, but the sentences of one table
have the same language.
I have to do a similarity search on them. It has to be very fast, because I
have to search for a few hundert
try again
2013/12/5 吕晓旭
>
> delete monitor image
>>
>>
>> 2013/12/5 吕晓旭
>>
>>>
>>>
>>> Hi, all
>>> We find so weird problem on our productive PostgreSQL system. And I
>>> don't know how could I do to resolve this problem.
>>> We deployed PostgreSQL 9.2.4 on two system environments, an
21 matches
Mail list logo
