On 10/06/2014 08:25 AM, Tim Mickelson wrote:
The administors (that are not from my company) are strongly against
changing the Postgresql version :( so if this is a bug from Postgresql
they want me to show a documentation that guarantees them that it will
be fixed on an upgrade.
You might want t
On 10/06/2014 11:29 PM, Tim Mickelson wrote:
What should I disable? Corrupt index sounds like a possible case, but
how do I fix this?
http://www.postgresql.org/docs/9.1/static/runtime-config-query.html
enable_indexscan (boolean)
Enables or disables the query planner's use of index-scan p
El 03/10/14 a las 16:24, Israel Brewster escibió:
> I have a Postgresql 9.3.5 server running on CentOS 6.5. In looking at
> some stats today, I saw that it was handling about 4-5
> transactions/second (according to the SELECT
> sum(xact_commit+xact_rollback) FROM pg_stat_database; query), and an
>
Adrian Klaver writes:
> SET enable_indexscan=off;
> EXPLAIN ANALYZE DELETE query
> SET enable_indexscan=on;
Note that you'd probably best do this in a fresh session, since the
supposed problem is being tickled by a foreign-key check. I think
the plans for those get cached, so if you'd already
>I've been able to fix most of my slow queries into something more acceptable,
>but I haven't been able to shave any time off this one. I'm hoping someone
>has another strategy.
>
>I have 2 tables:
>resource
>resource_2_tag
>
>I want to calculate the top 25 "tag_ids" in "resourc
BTW, where can I find a list of type1->type2 pairs that doesn't
require full table lock for conversion?
ps. Sorry for top posting.
On Mon, Oct 6, 2014 at 4:20 PM, Tom Lane wrote:
> Melvin Davidson writes:
>> Also, don't forget to test for relkind = 'r'. My bad from before.
>
> In principle you
On Oct 7, 2014, at 10:02 AM, Marc Mamin wrote:
> Hi,
> it seems to me that your subquery may deliver duplicate ids.
> And with the selectivity of your example, I would expect an index usage
> instead of a table scan. You may check how up to date your statistics are
> and try to raise the statist
Sergey Konoplev writes:
> BTW, where can I find a list of type1->type2 pairs that doesn't
> require full table lock for conversion?
There aren't any. Sometimes you can skip a table rewrite, but that
doesn't mean that a lesser lock is possible.
regards, tom lane
--
Sen
On Tue, Oct 7, 2014 at 10:16 AM, Tom Lane wrote:
> Sergey Konoplev writes:
>> BTW, where can I find a list of type1->type2 pairs that doesn't
>> require full table lock for conversion?
>
> There aren't any. Sometimes you can skip a table rewrite, but that
> doesn't mean that a lesser lock is pos
Sergey Konoplev writes:
> On Tue, Oct 7, 2014 at 10:16 AM, Tom Lane wrote:
>> Sergey Konoplev writes:
>>> BTW, where can I find a list of type1->type2 pairs that doesn't
>>> require full table lock for conversion?
>> There aren't any. Sometimes you can skip a table rewrite, but that
>> doesn't
On Tue, Oct 7, 2014 at 11:02 AM, Tom Lane wrote:
> Roughly speaking it's the pairs that have a binary (WITHOUT FUNCTION)
> coercion according to pg_cast, although we have special logic for a few
> cases such as varchar(M) -> varchar(N).
That ones?
select t1.typname, t2.typname
from pg_cast, pg_t
I have a table with over 1MM records and 15 columns.
I had created a "unique index" on a mix of two columns to enforce a constraint
: (resource_type_id, lower(archive_pathname))
i've noticed that searches never use this. no matter what I query, even if
it's only the columns in the index. I'm
On 10/7/2014 4:44 PM, Jonathan Vanasco wrote:
I had created a "unique index" on a mix of two columns to enforce a constraint
: (resource_type_id, lower(archive_pathname))
i've noticed that searches never use this. no matter what I query, even if
it's only the columns in the index. I'm seeing
On 10/6/14, 6:10 PM, Gavin Flower wrote:
Even if timestamps are used extensively, you'd have to be careful joining on them.
You may have information valid at T1 and changing at T3, but the transaction has T2,
where T1 < T2 < T3 - the appropriate set of data would be associated with T1,
would w
On 10/6/14, 6:16 PM, Tom Lane wrote:
Jim Nasby writes:
Just a heads-up: each of those ALTER's will rewrite the table, so unless your
database is tiny this will be a slow process. There's ways to work around that,
but they're significantly more complicated.
I think he's trying to get rid of
On 10/03/2014 6:28 pm, Andy Colson wrote:
On 10/03/2014 04:40 PM, Alan Hodgson wrote:
On Friday, October 03, 2014 11:24:31 AM Israel Brewster wrote:
I have a Postgresql 9.3.5 server running on CentOS 6.5. In looking at
some
stats today, I saw that it was handling about 4-5 transactions/second
On 08/10/14 13:29, Jim Nasby wrote:
On 10/6/14, 6:10 PM, Gavin Flower wrote:
Even if timestamps are used extensively, you'd have to be careful
joining on them. You may have information valid at T1 and changing at
T3, but the transaction has T2, where T1 < T2 < T3 - the appropriate
set of data
I am in the process of migrating a bunch of databases and associated CGI
scripts from 9.1.4 to 9.3 (and from 32-bit to 64-bit).
The database migration has been successful but I have an issue with psql
connections from CGI scripts.
I can connect to the 9.3 server locally with psql from the com
Stephen Davies writes:
> I am in the process of migrating a bunch of databases and associated CGI
> scripts from 9.1.4 to 9.3 (and from 32-bit to 64-bit).
> The database migration has been successful but I have an issue with psql
> connections from CGI scripts.
> I can connect to the 9.3 serve
On 14/10/08 12:51, Stephen Davies wrote:
> I am in the process of migrating a bunch of databases and associated CGI
> scripts from
> 9.1.4 to 9.3 (and from 32-bit to 64-bit).
>
> The database migration has been successful but I have an issue with psql
> connections from CGI scripts.
>
> I can
The permissions on the socket are 777 owner/group postgres.
I installed the 9.3 onto the Centos 7 server using the repo at postgresql.org.
(http://yum.postgresql.org/9.3/redhat/rhel-$releasever-$basearch)
There is no /var/run/postgresql and find cannot find another socket anywhere
else.
Cheer
Hi
http://forum.myways.su/felt.php?drive=bhankyuytv3630es
brick...@gmail.com
22 matches
Mail list logo
