Hi Team,
Today also we faced issue in autovacuum.. Is there any workaround for this
instead of upgrading,, If yes means can you please give me tuning
parameters..
> log_autovacuum_min_duration = 0
That is good for debugging. But what are you seeing in the log as the
result of this?
There is n
On Sat, Aug 10, 2013 at 10:32 AM, Timothy Kane wrote:
>
> Hi all,
>
> I seem to be having some grief with the 9.1.9 query planner favouring an
> index scan + merge join, over a sequential scan + hash join.
> Logically I would have considered the index+merge to be faster, as suggested
> by the expl
-- Forwarded message --
From: Selena Deckelmann
Date: 2013/8/13
Subject: Re: Error Stack builder
To: Thodi Viola
Please contact pgsql-general@postgresql.org for help.
-selena
2013/8/13 Thodi Viola
>
> Dear Sr.
>
> Could you please help me to fix the error in attachment. I'm
On 08/13/2013 08:57 AM, Thodi Viola wrote:
Dear Srs
Could you please help me to fix the error shown in attachment, i'm use
windows 7.
What is in the error log mentioned in the pop up?
--
Adrian Klaver
adrian.kla...@gmail.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresq
On Sat, Aug 10, 2013 at 5:24 PM, Tim Kane wrote:
>
> Again, just thinking out loud here.. In a scenario where specific
> clustering isn't an option...
> I wonder if the query planner should consider the physical
> distribution/ordering of values on disk, and use that as a factor when
> applyin
I'm upgrading our database from 8.4 to 9.2 and I've run across a view that is
no longer working. When selecting from the view, I get a permission denied
error on one of the referenced tables. However, I can run the view's query
directly without problems and I have read access to all the tab
Hi!
What is the difference between both? cancel sends QUIT while terminate sends
TERM, but what effect does this have on the backends, shared memory, etc?
I had some processes stuck in IDLE in transaction after a machine died (through
pgbouncer), and cancel did not close the connections, while
François Beausoleil wrote:
> What is the difference between both?
> I had some processes stuck in IDLE in transaction after a machine
> died (through pgbouncer), and cancel did not close the
> connections, while terminate did kill the transactions.
> The docs at
> http://www.postgresql.org/docs
Hello,
When the client library (version 9.2.x) is compiled with a MinGW-w64 environment
the resulting libpq.dll will not function. This has been reported previously
with two bug reports, which have gone untouched.
Bug 8151:
http://www.postgresql.org/message-id/e1ubelm-0007nk...@wrigleys.postgresq
Le 2013-08-13 à 13:25, Kevin Grittner a écrit :
> François Beausoleil wrote:
>
>> What is the difference between both?
>
>> I had some processes stuck in IDLE in transaction after a machine
>> died (through pgbouncer), and cancel did not close the
>> connections, while terminate did kill the t
The error mentioned is orcan you see
the attachment.
Thodi Viola
2013/8/13 Adrian Klaver
> On 08/13/2013 08:57 AM, Thodi Viola wrote:
>
>> Dear Srs
>>
>> Could you please help me to fix the error shown in attachment, i'm use
>> windows 7.
>>
>>
>>
> What is in the error log mentioned in the
Brian Hirt writes:
> I'm upgrading our database from 8.4 to 9.2 and I've run across a view that is
> no longer working. When selecting from the view, I get a permission denied
> error on one of the referenced tables. However, I can run the view's query
> directly without problems and I have
On 8/13/2013 10:35 AM, Michael Cronenworth wrote:
What environment does EnterpriseDB use to create their Windows binaries?
They use Microsoft Visual C (I forget the exact version, but I believe
most recent versions are supported, including the "Express" versions).
--
john r pierce
On 08/13/2013 10:29 AM, Thodi Viola wrote:
The error mentioned is
orcan you see the attachment.
Well either no password or the wrong password supplied for the postgres
user. I do not use StackBuilder, so someone else will need to help out
with the proper place/method to supply the password.
None of the relations used by vcredit_info are views. They are all tables.
Oddly, I dropped the view and recreated it and the problem went away. Earlier
I was just using create or replace view and the problem persisted. The schema
was created by using pg_restore from an 8.4 custom dump.
On 08/13/2013 01:40 PM, John R Pierce wrote:
> They use Microsoft Visual C (I forget the exact version, but I believe most
> recent versions are supported, including the "Express" versions).
Then MinGW should be capable of producing the same binaries.
I've tried early gcc 4.7 and the latest gcc 4
Brian Hirt writes:
> None of the relations used by vcredit_info are views. Â They are all
> tables. Â Oddly, I dropped the view and recreated it and the problem went
> away. Â Earlier I was just using create or replace view and the problem
> persisted.
Hm. I think that CREATE OR REPLACE VIEW m
I have a view which is very slow to computer, but doesn't change often.
I'd like to materialize it. I thought I'd do a simple poor man's materialize by:
1) ALTER VIEW myview RENAME to _myview
2) SELECT * INTO myview FROM _myview
The only problem is that all my other views, which are dependent on
I'm doing a JOIN which is very slow:
JOIN t ON t.f1 LIKE (q.f1 || '%')
t1 has an INDEX on (f1, f2) which I thought would help for this. But
Postgres seems to still use a (very slow) Nested Loop. What type of
index would be appropriate for this?
(My goal is to join on a substring starting from
On Sun, Aug 11, 2013 at 9:59 PM, Victor Hooi wrote:
> Hmm, aha, so the ORDER BY RANDOM behaviour hasn't changed - just to confirm
> - this means that Postgres will duplicate the table, add a new column,
> generate random numbers for every record, then sort by that new column,
> right?
It doesn't
I noticed that when I have an index on (a,b) of table t, and I do an
SELECT * FROM t ORDER BY a ASC, it doesn't use the index. When I
create a new index of only a, it does use the index. Why is that?
And, more importantly, when I do a query involving a merge join of
table t, which requires sorti
On 8/13/13, Robert James wrote:
> I noticed that when I have an index on (a,b) of table t, and I do an
> SELECT * FROM t ORDER BY a ASC, it doesn't use the index. When I
> create a new index of only a, it does use the index. Why is that?
>
> And, more importantly, when I do a query involving a m
On 14/08/13 12:02, Robert James wrote:
I noticed that when I have an index on (a,b) of table t, and I do an
SELECT * FROM t ORDER BY a ASC, it doesn't use the index. When I
create a new index of only a, it does use the index. Why is that?
And, more importantly, when I do a query involving a me
On 8/13/2013 5:25 PM, Michael Cronenworth wrote:
On 08/13/2013 01:40 PM, John R Pierce wrote:
They use Microsoft Visual C (I forget the exact version, but I believe most
recent versions are supported, including the "Express" versions).
Then MinGW should be capable of producing the same binarie
On 8/13/2013 2:25 PM, Michael Cronenworth wrote:
On 08/13/2013 01:40 PM, John R Pierce wrote:
>They use Microsoft Visual C (I forget the exact version, but I believe most
>recent versions are supported, including the "Express" versions).
Then MinGW should be capable of producing the same binari
On 08/14/2013 08:57 AM, John R Pierce wrote:
>
> no. GCC uses a totally different libc in its generated code. that alone
> ensures its binaries are not directly comparable.linking code with
> incompatible libc's is gonna result in some gnarly messes, imagine what
> kind of ugly stuff could ha
On 08/14/2013 06:05 AM, Robert James wrote:
> I'm doing a JOIN which is very slow:
>
> JOIN t ON t.f1 LIKE (q.f1 || '%')
>
> t1 has an INDEX on (f1, f2) which I thought would help for this. But
> Postgres seems to still use a (very slow) Nested Loop. What type of
> index would be appropriate fo
On 8/13/13, Craig Ringer wrote:
> On 08/14/2013 06:05 AM, Robert James wrote:
>> I'm doing a JOIN which is very slow:
>>
>> JOIN t ON t.f1 LIKE (q.f1 || '%')
>>
>> t1 has an INDEX on (f1, f2) which I thought would help for this. But
>> Postgres seems to still use a (very slow) Nested Loop. What
On Aug 12, 2013, at 12:47 PM, Tom Lane wrote:
> Matt Solnit writes:
>> 2. The function seems to work consistently when I do a SELECT
>> SUM(mycol) without any GROUP BY. It's only when I add grouping that
>> the failures happen. I'm not sure if this is a real clue or a red
>> herring.
>
> That
Hi all,
I am new in this group and need some help from your side.
We have a mediation product which is initially using Oracle as database.
Some of our customer interested to move Postgres 9.1.
Our mediation product storing some configuration related information in data
base and some type of lo
Hi all,
I am new in this group and need some help from your side.
We have a mediation product which is initially using Oracle as database.
Some of our customer interested to move Postgres 9.1.
Our mediation product storing some configuration related information in data
base and some type of lo
On Wed, Aug 14, 2013 at 11:10 AM, M Tarkeshwar Rao <
m.tarkeshwar@ericsson.com> wrote:
> Hi all,
>
> I am new in this group and need some help from your side.
>
> We have a mediation product which is initially using Oracle as database.
>
> Some of our customer interested to move Postgres 9.1.
32 matches
Mail list logo
