On 15.01.2013, at 17:32, Jeff Janes wrote:
> T.E., Fortunately in point releases from August 2012 (9.0.9, 9.1.5,
> etc.), the default server log settings will log both the cancel and
> the command triggering the cancel. So if you are running an up to
> date server, you can just look in the logs
On 15.01.2013, at 16:36, Tom Lane wrote:
> "T. E. Lawrence"
> > So, apparently, we need to interrupt the heavy imports on some reasonable
>> intervals and do manual VACUUM ANALYZE?
>
> Data import as such, no matter how "heavy", shouldn't be a
On 15.01.2013, at 05:45, Jeff Janes wrote:
>> Which makes me think that, as we grew the database more than 250 times in
>> size over a 2-3 months period, relying on autovacuum (some tables grew from
>> 200k to 50m records, other from 1m to 500m records), the autovacuum has
>> either let us do
On 15.01.2013, at 00:28, Rich Shepard wrote:
> On Tue, 15 Jan 2013, T. E. Lawrence wrote:
>
>> When forced on Linux we like Debian because it is so conservative (which
>> can sometimes drive one crazy, especially if one needs some cutting edge
>> feature).
>
> Hey guys,
>
> I'm not sure the last time I saw this discussion, but I was somewhat curious:
> what would be your ideal Linux distribution for a nice solid PostgreSQL
> installation? We've kinda bounced back and forth between RHEL, CentOS, and
> Ubuntu LTS, so I was wondering what everyone els
RESOLVED
--
Dear all,
Thank you for your great help and multiple advices.
I discovered the problem and I have to say that it is very stupid and strange.
Here is what happened.
>From all advices I tried first partial index. The index was built and there
>was no change in the speed of the slow q
Hi and thank you!
On 12.01.2013, at 11:52, Eduardo Morras wrote:
>> With the last "AND b.value=..." the query is extremely slow (did not wait
>> for it to end, but more than a minute), because the value column is not
>> indexed (contains items longer than 8K).
>
> You can construct your own h
Hi and thank you for your notes!
> You really ought to include the output of EXPLAIN ANALYZE in cases such as
> these (if it doesn't already point you to the culprit).
I'll do so, it takes quite long...
> Most likely you'll find that the last condition added a sequential scan to
> the query pl
On 12.01.2013, at 07:10, Amit kapila wrote:
> You can try once with below query:
> Select * from (SELECT a.id,b.value FROM table_a a, table_b b WHERE ... AND
> ... ) X where X.value=...;
>
> If this doesn't work can you send the Explain .. output for both queries(the
> query you are using and t
Hello,
I have a pretty standard query with two tables:
SELECT table_a.id FROM table_a a, table_b b WHERE ... AND ... AND b.value=...;
With the last "AND b.value=..." the query is extremely slow (did not wait for
it to end, but more than a minute), because the value column is not indexed
(conta
> I am researching how to set up a schema for querying a set of tags
> associated with an object.
I would be interested in hearing your conclusions.
I am currently researching in a similar direction.
We have streaming replication where the slaves are used for data mining,
storing currently abou
> Have you looked at the below?:
>
> http://www.postgresql.org/docs/9.2/interactive/hot-standby.html#HOT-STANDBY-CONFLICT
>
> 25.5.2. Handling Query Conflicts
Yes, thank you!
I am hoping to hear more from people who have running 9.2 systems w/ between
100m and 1b records, w/ streaming replicat
Hello,
We are running 9.2 w/ streaming replication.
The slave is used for heavy tsearch based data mining.
Apparently depending on the business of the master the slave queries fail with
different frequency with the following message —
ERROR: canceling statement due to conflict with recovery
D
13 matches
Mail list logo
