I am working with street address data in which 'first st' has been
entered as '1 st' and so on. So I have created a text search
dictionary with entries:
first 1
1st 1
And initially it seems to be working properly:
SELECT ts_lexize('rwg_synonym','first');
ts_lexize
---
{1}
S
On 26.11.2011 19:08, Tom Lane wrote:
> Tomas Vondra writes:
>> Anyway the output is a bit strange. It's writing a lot of temp files
>> that are significantly smaller (about 3MB) than work_mem (128MB).
>
> The most obvious guess about what's doing that is a hash join that has
> a drastic overestim
On Friday, November 25, 2011 11:28:06 pm Condor wrote:
>
> No, charset of databases is the same. I use the same ENV when I upgrade
> sql servers
> and recreate psql database directory.
>
> About client encoding, I never ever has before a configured postgresql
> on my work station
> where I conne
On Saturday, November 26, 2011 10:18:56 AM Carlos Henrique Reimer wrote:
> Hi,
>
> We're planning to move our postgreSQL database from one CPU box to another
> box.
>
> I'm considering an alternative procedure for the move as the standard one
> (pg_dump from the old, copy dump to the new box, psq
Hi,
We're planning to move our postgreSQL database from one CPU box to another
box.
I'm considering an alternative procedure for the move as the standard one
(pg_dump from the old, copy dump to the new box, psql to restore in the
new) will take about 10 hours to complete. The ideia is installing
Dne 26.11.2011 17:47, Gaëtan Allart napsal(a):
> Rahh :/
>
> It's getting worse and worse :/ Database has to be restarted every 2 hours
> causing much traffic loss :/
>
> As far as the server is concerned, it was running great 7 days ago and had
> been running like this for months. I really don't
Tomas Vondra writes:
> Anyway the output is a bit strange. It's writing a lot of temp files
> that are significantly smaller (about 3MB) than work_mem (128MB).
The most obvious guess about what's doing that is a hash join that has
a drastic overestimate of how many rows it has to hash, so that it
Dne 26.11.2011 18:08, Gaëtan Allart napsal(a):
> Uhm…
>
> I'm seeing dozens and dozens of temporary file creations in logs :
>
> LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp15388.1399", size 23912
> LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp15388.211", size
> 2761788
> LOG: tem
Uhm…
I'm seeing dozens and dozens of temporary file creations in logs :
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp15388.1425", size 25340
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp15388.195", size
2720340
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp13772.3495", size 24
Rahh :/
It's getting worse and worse :/ Database has to be restarted every 2 hours
causing much traffic loss :/
As far as the server is concerned, it was running great 7 days ago and had
been running like this for months. I really don't get why it suddenly went
"I/oing"Š
Here's the current post
Hello Robert,
I'm having around 30 active connections (average).
As far as disk layout is concerned, ever thing's on the same disk (raid 1
with 2 SSDs).
Gaëtan
Le 26/11/11 15:25, « Robert Treat » a écrit :
>On Fri, Nov 25, 2011 at 6:48 PM, Gaëtan Allart wrote:
>> Here are the latest checkpoin
On Fri, Nov 25, 2011 at 6:48 PM, Gaëtan Allart wrote:
> Here are the latest checkpoint logs :
>
> LOG: checkpoint complete: wrote 842 buffers (0.1%); 0 transaction log
> file(s) added, 0 removed, 0 recycled; write=168.970 s, sync=0.005 s,
> total=168.977 s
> LOG: checkpoint starting: time
> LOG:
On 26 Listopad 2011, 10:45, Gaëtan Allart wrote:
> A better view of iotop :
>
> TID PRIO USER DISK READ DISK WRITE SWAPIN IOCOMMAND
> 31875 be/4 postgres0.00 B/s 15.23 M/s 0.00 % 0.00 % postgres:
> database database 46.105.104.205(50228) SELECT
> 30985 be/4 postgres0.
A better view of iotop :
TID PRIO USER DISK READ DISK WRITE SWAPIN IOCOMMAND
16974 be/4 postgres 46.33 K/s0.00 B/s 0.00 % 7.21 % postgres:
database database 46.105.111.92(54930) idle
383 be/4 postgres7.72 K/s0.00 B/s 0.00 % 1.56 % postgres:
database database
14 matches
Mail list logo
