Hi
The follow query below works in one database but not on another database.
The databases are similar but independent of each other. From the previous
post I found that: *This is fixed by casting the first argument to **text*
*:,* but I can’t see which COALESCE to fix out the several COALESCE
Sorry
I found the problem, it’s data problem in another database, it’s trying to
convert numeric null but of which it’s not a null data, it’s a blank data.
*From:* Khangelani Gama [mailto:kg...@argility.com]
*Sent:* Tuesday, May 20, 2014 12:24 PM
*To:* pgsql-general@postgresql.org
*Subject:*
Greetings.
I have a partitioned table, that can be reproduced the following way:
CREATE TABLE ara (
ara_id int4,
namevarchar(11),
run_id int4,
set_id int4,
created_at timestamp,
CONSTRAINT p_ara PRIMARY KEY (ara_id)
);
DO $partition$
DECLARE
Victor Yegorov vyego...@gmail.com writes:
How can I enforce pruning to kick in for the initial expressions?
You already found out: use constants. The planner can't remove
partitions on the basis of clauses involving volatile, or even
stable, functions, because their results might be different
2014-05-20 14:26 GMT+03:00 Tom Lane t...@sss.pgh.pa.us:
Victor Yegorov vyego...@gmail.com writes:
How can I enforce pruning to kick in for the initial expressions?
You already found out: use constants. The planner can't remove
partitions on the basis of clauses involving volatile, or even
Hi,
I would like know whether there is some way how to revoke permission for doing
recovery (showing prepared transactions and working with them) for a user?
I've tried someting like
revoke all on pg_catalog.pg_prepared_xacts from public;
and
revoke all on function pg_prepared_xacts from
Is there a way to force a specific index to be removed from
consideration in planning a single query?
Specifically, on a 60-million-row table I have an index that is a
candidate for removal. I have identified the sets of nightly queries
that use the index but before dropping it I would like
On 5/20/14, 1:38 PM, Steve Crawford wrote:
Is there a way to force a specific index to be removed from
consideration in planning a single query?
hi Steve,
What is the query? Or at least a sanitized but complete version?
Thanks,
Seamus
PS. I've had luck hinting with OFFSET 0 but it might not
Steve Crawford wrote:
Is there a way to force a specific index to be removed from
consideration in planning a single query?
Specifically, on a 60-million-row table I have an index that is a
candidate for removal. I have identified the sets of nightly queries
that use the index but before
On 05/20/2014 09:44 AM, Seamus Abshere wrote:
On 5/20/14, 1:38 PM, Steve Crawford wrote:
Is there a way to force a specific index to be removed from
consideration in planning a single query?
hi Steve,
What is the query? Or at least a sanitized but complete version?
I've now resolved the
On 05/20/2014 10:44 AM, Alvaro Herrera wrote:
Steve Crawford wrote:
Is there a way to force a specific index to be removed from
consideration in planning a single query?
Specifically, on a 60-million-row table I have an index that is a
candidate for removal. I have identified the sets of
On 05/20/2014 11:48 AM, Steve Crawford wrote:
...
What would happen if you did:
BEGIN;
DROP INDEX bothersome_idx;
INSERT INTO indexed_table...;
ROLLBACK;
Never mind. Thought it through.
Cheers,
Steve
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to
Steve Crawford scrawf...@pinpointresearch.com writes:
On 05/20/2014 10:44 AM, Alvaro Herrera wrote:
If you can afford to lock the table for a while, the easiest is
BEGIN;
DROP INDEX bothersome_idx;
EXPLAIN your_query;
ROLLBACK;
Interesting. But what do you mean by a while? Does the above
Steve Crawford wrote
On 05/20/2014 10:44 AM, Alvaro Herrera wrote:
Steve Crawford wrote:
Is there a way to force a specific index to be removed from
consideration in planning a single query?
Specifically, on a 60-million-row table I have an index that is a
candidate for removal. I have
Steve Crawford wrote:
On 05/20/2014 10:44 AM, Alvaro Herrera wrote:
If you can afford to lock the table for a while, the easiest is
BEGIN;
DROP INDEX bothersome_idx;
EXPLAIN your_query;
ROLLBACK;
Interesting. But what do you mean by a while? Does the above keep
the index intact (brief
On Tue, May 20, 2014 at 11:48 AM, Steve Crawford
scrawf...@pinpointresearch.com wrote:
On 05/20/2014 10:44 AM, Alvaro Herrera wrote:
Steve Crawford wrote:
Is there a way to force a specific index to be removed from
consideration in planning a single query?
Specifically, on a
On Tue, May 20, 2014 at 3:20 PM, Jeff Janes [via PostgreSQL]
ml-node+s1045698n580459...@n5.nabble.com wrote:
On Tue, May 20, 2014 at 11:48 AM, Steve Crawford [hidden
email]http://user/SendEmail.jtp?type=nodenode=5804596i=0
wrote:
On 05/20/2014 10:44 AM, Alvaro Herrera wrote:
Steve
Jeff Janes wrote:
Best case, 'A while' means however long it takes the explain (possibly
analyze) to run, and for you to then type 'rollback;'
worse case, someone else is already holding an incompatible lock (i.e. any
lock) on the table, and is going to hang on to it for a long while, so
I want to set up a new PostgreSQL database from an XML database file. It seems
like there should be an obvious way to do this but I can't seem to find any
directions anywhere. How is this sort of thing normally done?
The database is available to the public here:
On 5/20/2014 9:16 PM, Aram Fingal wrote:
I want to set up a new PostgreSQL database from an XML database file. It seems
like there should be an obvious way to do this but I can't seem to find any
directions anywhere. How is this sort of thing normally done?
you'd need some sort of tool that
20 matches
Mail list logo
