What should I disable? Corrupt index sounds like a possible case, but
how do I fix this?
EXPLAIN ANALYZE
select * from cubesocialnetwork.tmp_autenticazionesocial where
idautenticazionesocial = 1622
Index Scan using tmpautenticazione on tmp_autenticazionesocial
(cost=0.00..8.27 rows=1
On 06 Oct 2014, at 10:02, Richard Frith-Macdonald
richard.frith-macdon...@brainstorm.co.uk wrote:
I'm wondering if anyone can help with advice on how to manage large
lists/sets of items in a postgresql database.
I have a database which uses multiple lists of items roughly like this:
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
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
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 adrian.kla...@aklaver.com 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
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 resource_2_tag
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 t...@sss.pgh.pa.us wrote:
Melvin Davidson melvin6...@gmail.com writes:
Also, don't forget to test for relkind = 'r'. My bad
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 statistic
Sergey Konoplev gray...@gmail.com 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
On Tue, Oct 7, 2014 at 10:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Sergey Konoplev gray...@gmail.com 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
Sergey Konoplev gray...@gmail.com writes:
On Tue, Oct 7, 2014 at 10:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Sergey Konoplev gray...@gmail.com 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
On Tue, Oct 7, 2014 at 11:02 AM, Tom Lane t...@sss.pgh.pa.us 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
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
On 10/6/14, 6:16 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com 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
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
Stephen Davies sdav...@sdc.com.au 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
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 connect
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.
Hi
http://forum.myways.su/felt.php?drive=bhankyuytv3630es
brick...@gmail.com
24 matches
Mail list logo
