> hi,
>
> how i can make plugins icon active in pgadmin3 in ubuntu??
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks & Regards,
>
> Himanshu Rana
> Project Officer,
> GIS Department,
> Foundation of Ecological Security,
> Anand, Gujarat- 388001
>
--
Dave Page
PostgreSQL Core Team
http:/
2011/5/17 Eduardo Velasquez M :
>
> En Pgadmin III el Query Tools no esta funcionando. Se bloquea. Que hay que
> hacer para poder habilitarlo.
>
>
Este no es un bug de postgres sino un problema en pgAdmin III, sería
preferible que envies la consulta a la lista de correo de soporte de
pgAdmin (pgad
En Pgadmin III el Query Tools no esta funcionando. Se bloquea. Que hay que
hacer para poder habilitarlo.
Eduardo Velasquez M
I made a brute force check and indeed, for one of the parameters the query was
switching to sequential scans (or bitmaps scans with condition on survey_pk=16
only if sequential scans were off). After closer look at the plan cardinalities
I thought it would be worthy to increase histogram size an
Krzysztof Nienartowicz writes:
> Logs of the system running queries are not utterly clear, so chasing the
> parameters for the explosive query is not that simple (shared logs between
> multiple threads), but from what I see there is no difference between them
> and the plan looks like (without rem
Hello,
Thank you for the clarifications. The plan as run from the psql looks ok,
also did not notice any specific locks for this particular query.
Logs of the system running queries are not utterly clear, so chasing the
parameters for the explosive query is not that simple (shared logs between
mul
Krzysztof Nienartowicz writes:
> surveys-> SELECT t1.SURVEY_PK, t1.SOURCE_PK, t1.TSTYPE, t1.VALS
> surveys-> FROM sources t0 ,TS t1 where
> surveys-> (t0.SURVEYID = 16 AND t0.SRCID >= 203510110032281 AND
> t0.SRCID <= 203520107001677 and t0.SURVEYID = t1.SURVEY_PK AND t0.SRCID =
> t1.SOURCE_
Hello,
Sorry for the re-post - not sure list is the relevant one, I included
slightly changed query in the previous message, sent to bugs list.
I have an ORM-generated queries where parent table keys are used to
fetch the records from the child table (with relevant FK indicies),
where child tabl
Hello,
I have an ORM-generated queries where parent table keys are used to
fetch the records from the child table (with relevant FK indicies),
where child table is partitioned. My understanding is that Postgres is
unable to properly use constraint exclusion to query only a relevant
table? Half of t
Firstly, this doesn't seem like a bug at all. So, I think you're in the
wrong list. That said, here are some hints that might help you get started
through the troubleshooting necessary:
1) Are you able to connect to the server using the psql command line utility
(it's best to start there before mo
Abhishek Maurya wrote:
> while connecting php with database created in postgres,we r facing
> one error ..errror is that its demanding a password of
> postgres..but while installing or using postgres we hadnt gave any
> password.. so hw cn we solve this problem..
You haven't really given enoug
sir,
while connecting php with database created in postgres,we r facing one error
..errror is that its demanding a password of postgres..but while installing
or using postgres we hadnt gave any password.. so hw cn we solve this
problem..
On Sat, Apr 25, 2009 at 9:52 AM, Tom Lane wrote:
> Daniel Grace writes:
> > The following nonsensical query causes PostgreSQL to fail with ERROR:
> plan
> > should not reference subplan's variable. (This was stripped down from an
> > 'useful' query that triggered the same bug). First encounter
Daniel Grace writes:
> The following nonsensical query causes PostgreSQL to fail with ERROR: plan
> should not reference subplan's variable. (This was stripped down from an
> 'useful' query that triggered the same bug). First encountered on 8.3.4,
> reproduced on 8.3.7
Patch is here:
http://arc
Daniel Grace writes:
> No luck there either (runs, but with incorrect results), but since I know
> this isn't a support list and is a bugs list I just would like to point out
> that: Even though what I was doing that triggered the bug is apparently
> incorrect and 'silly', it's still possible that
No luck there either (runs, but with incorrect results), but since I know
this isn't a support list and is a bugs list I just would like to point out
that: Even though what I was doing that triggered the bug is apparently
incorrect and 'silly', it's still possible that some complicated legitimate
q
I wrote:
> I'm talking about the underlined SELECT, not the one inside the
> aggregate. AFAICS this one is totally useless.
Oh, wait. It is useless in the query as written, but now that I think
twice about what you're trying to accomplish, you do need three levels
of SELECT keywords. Just not l
Daniel Grace writes:
> On Fri, Apr 24, 2009 at 5:38 PM, Tom Lane wrote:
>> Hmmm ... I guess something is getting confused about the level of query
>> nesting. FWIW, you can avoid the bug in these two examples by omitting
>> the inner "SELECT" keyword, which is useless anyway. Perhaps it is
>> n
On Fri, Apr 24, 2009 at 5:38 PM, Tom Lane wrote:
> Daniel Grace writes:
> > The following nonsensical query causes PostgreSQL to fail with ERROR:
> plan
> > should not reference subplan's variable. (This was stripped down from an
> > 'useful' query that triggered the same bug). First encounter
Daniel Grace writes:
> The following nonsensical query causes PostgreSQL to fail with ERROR: plan
> should not reference subplan's variable. (This was stripped down from an
> 'useful' query that triggered the same bug). First encountered on 8.3.4,
> reproduced on 8.3.7
Hmmm ... I guess somethin
The following nonsensical query causes PostgreSQL to fail with ERROR: plan
should not reference subplan's variable. (This was stripped down from an
'useful' query that triggered the same bug). First encountered on 8.3.4,
reproduced on 8.3.7
BEGIN;
CREATE SCHEMA bug_schema;
SET SEARCH_PATH='bug_
On 2008-11-30, at 13:31, Greg Stark wrote:
On Fri, Nov 28, 2008 at 8:08 PM, Grzegorz Jaskiewicz
<[EMAIL PROTECTED]> wrote:
work_mem = 128140 # min 64, size in KB
maintenance_work_mem = 65535# min 1024, size in KB
Incidentally it's very odd to see maintenance
On Fri, Nov 28, 2008 at 8:08 PM, Grzegorz Jaskiewicz
<[EMAIL PROTECTED]> wrote:
> work_mem = 128140 # min 64, size in KB
> maintenance_work_mem = 65535# min 1024, size in KB
Incidentally it's very odd to see maintenance_work_mem less than
work_mem. work_mem is use
hey folks
(please CC, I'm not subscribed).
I am trying to merge duplicates of two fields in a rather large table
(139M rows, about 7GB of data).
creating helper table, that would hold it.
my feeling is, postgresql shouldn't go beyond memory bounds I am
setting it in conf, never had any probl
Roger Merritt wrote:
Hi,
I have tried several installs of postgresql-8.1.3-1 and postgresql-8.1.4-1,
with psqlodbc-08_02_0002.zip and PgOleDb-1.0.0.20.zip.
After each uninstall I delete the entire contents of the C:\Program
Files\PostgreSQL directory.
I am using VB6 SP6b.
My 'Connection' stri
Hi,
I have tried several installs of postgresql-8.1.3-1
and postgresql-8.1.4-1, with psqlodbc-08_02_0002.zip and PgOleDb-1.0.0.20.zip.
After each uninstall I delete the entire contents of
the C:\Program Files\PostgreSQL directory.
I am using VB6 SP6b.
My ‘Connection’ string
On Tue, 04 Jul 2006, Tom Lane wrote:
> Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> > So why estimate regex expressions if there is no estimation possible?
> > Let's set this estimate to be pessimistic (match everything or
> > everything not null) and it will choose better plans.
>
> Better pla
Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> So why estimate regex expressions if there is no estimation possible?
> Let's set this estimate to be pessimistic (match everything or
> everything not null) and it will choose better plans.
Better plans for this specific example, worse plans for othe
On Tue, Jul 04, 2006 at 04:44:08PM +0200, Tomasz Ostrowski wrote:
> On Tue, 04 Jul 2006, Tom Lane wrote:
>
> > I think the real problem here is that regex matching is the wrong
> > tool for the job. Have you looked into a full-text index
> > (tsearch2)?
>
> So much to do with so little time...
On Tue, 04 Jul 2006, Tom Lane wrote:
> I think the real problem here is that regex matching is the wrong
> tool for the job. Have you looked into a full-text index
> (tsearch2)?
So much to do with so little time...
I've briefly looked into it but:
- it's complicated;
- it is not needed - basi
Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> I think because there is no good solution to this - no statistical
> information is going to predict how much data will match a regular
> expression.
Well, it's certainly hard to imagine simple stats that would let the
code guess that, say, "warsa" an
On Mon, 03 Jul 2006, Tom Lane wrote:
> > -> Seq Scan on organization (cost=0.00..480.95 rows=1 width=4) (actual
> > time=0.071..69.702 rows=1892 loops=1)
> > Filter: ((organization_location)::text ~* 'warszawa'::text)
>
> How many rows are there in the organization table?
About 9000. And
On Mon, 2006-07-03 at 22:31 +0200, Tomasz Ostrowski wrote:
> I have a very slow query when enable_seqscan=on and very fast when
> enable_seqscan=off. My schema looks like this (relevant columns
> only):
> PS. Actual table and column names are different (they're in Polish)
> but I've translated them
Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> I have a very slow query when enable_seqscan=on and very fast when
> enable_seqscan=off.
Here's your problem:
> -> Seq Scan on organization (cost=0.00..480.95 rows=1 width=4)
> (actual time=0.071..69.702 rows=1892 loops=1)
>
I have a very slow query when enable_seqscan=on and very fast when
enable_seqscan=off. My schema looks like this (relevant columns
only):
create table organizations (
organization_id serial primary key,
organization varchar(200) not null,
organization_location varchar(55) n
On Tue, 27 Apr 2004, Nicholas Howell wrote:
> ebatcher=> select version();
> version
> -
> PostgreSQL 7.2.2 on i686-pc-linux-gnu, compiled by G
ebatcher=> select version();
version
-
PostgreSQL 7.2.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2
20020903 (Red Hat Linux 8.0 3.2-7)
(1
Hi,
Could u please explain why database installation should not be done using a
root user on Linux.
What kind of security hole does it tamper?
Regards,
Deepanshu
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
Bernd von den Brincken <[EMAIL PROTECTED]> writes:
> My client is psql via telnet on a Toshiba T550 laptop, my version():
>PostgreSQL 7.3.2 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4
> Now I tested it on a different machine (P-3 Server) with (almost) the same
> DB contents - it works fi
Hello Tom,
At 04.04.2003 00:22, you wrote:
Bernd von den Brincken <[EMAIL PROTECTED]> writes:
> a query ... produces an error 'Query was cancelled' -
> sometimes, depending on the search words.
That's really, really hard to believe. I suspect you've mis-analyzed
the situation. You sure your clie
Bernd von den Brincken <[EMAIL PROTECTED]> writes:
> a query that uses pattern matching like this:
>SELECT .. WHERE ( (content || authorname) ~* ( '.*gesellschaft.* |
> .*wirtschaft.*' ) )
> produces an error 'Query was cancelled' - sometimes, depending on the
> search words.
That's really,
Hello Bugs,
a query that uses pattern matching like this:
SELECT .. WHERE ( (content || authorname) ~* ( '.*gesellschaft.* |
.*wirtschaft.*' ) )
produces an error 'Query was cancelled' - sometimes, depending on the
search words.
Seems quite strange to me, I increased some postgresql.conf para
On Mon, 7 Oct 2002, Szymon Juraszczyk wrote:
> The table contains some 4,7 milion rows.
>
> Let's try to have look for entries with account = 570:
>
It looks to me it's estimating that 4275 rows will match account=570. If
you're using 7.2 and have analyzed, you may want to up the number of
Hi,
There is a bug in Postgresql query optimizer that makes the query that's
supposed to return an empty result perform considerably slower when LIMIT
clause is given. For exaple, the following query:
select * from login_history where account = 570 order by timestamp;
is performed in 0,28 m
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Shouldn't infinity be treated similar to NULL.
>
> Nope. It has a definite position in the sort order.
I was thinking about the optimizer's histogram, not the index ordering.
Anyway, seems you got it fixed already.
--
Bruce Momjian
> The reason I didn't see it here is that on my platform, the infinity
> timestamp values aren't represented as real IEEE infinities, and so the
> result isn't NAN.
>
> Seems like we could fix this either by forbidding use of real infinity
> for timestamp and float8 values ... probably not workab
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Shouldn't infinity be treated similar to NULL.
Nope. It has a definite position in the sort order.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaste
"Mike Quinn" <[EMAIL PROTECTED]> writes:
[ query behaves okay as
WHERE Crops.change_e > '10/1/2001'
but not as
WHERE '10/1/2001' < Crops.change_e
]
Ah-hah, I see it. The critical factor is that you have some +infinity
values in that timestamp column, so that the column data ra
ag20 wrote:
> Is there a reason that the expressions:
>
> Crops.change_e > '10/1/2001'
>
> '10/1/2001' < Crops.change_e
>
> when used in a WHERE clause of a query should yield
> a good plan for the first and a bad plan for the second?
Disclaimer: I'm tired and haven't tested this.
This "probl
"ag20" <[EMAIL PROTECTED]> writes:
> Is there a reason that the expressions:
> Crops.change_e > '10/1/2001'
> '10/1/2001' < Crops.change_e
> when used in a WHERE clause of a query should yield
> a good plan for the first and a bad plan for the second?
I think you have a broken installation. I
Is there a reason that the expressions:
Crops.change_e > '10/1/2001'
'10/1/2001' < Crops.change_e
when used in a WHERE clause of a query should yield
a good plan for the first and a bad plan for the second?
They both yield the same boolean value.
The attribute Crops.change_e is not involved
Temp tables don't interact well with plpgsql's attempts to cache query
plans for the queries in its functions. This is a bug, but a solution
is not close at hand.
In 7.1, you can work around this by using EXECUTE to execute the queries
on the temp table, thus forcing a re-plan on every execution
Rahul Gade ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
query first time works second time fails for one connection
Long Description
In fact i want to execute the code which i hade placed in remark, but since the
orderby, l
<[EMAIL PROTECTED]> writes:
> I have PostgreSQL v7.02 in RedHat 6.2;
>
> I have problem with is Query:
> select name, 'user' as class from smuser u=
> nion=20
> select name, 'group' as class from smgroup order by class;
>
Please turn off HTML mail :-(
The problem is with the nonspecific-typ
On Mon, 8 Jan 2001 15:50:42 -0400, <[EMAIL PROTECTED]> wrote:
> I have PostgreSQL v7.02 in RedHat 6.2;
>
> I have problem with is Query:
> select name, 'user' as class from smuser union select name, 'group' as class from
>smgroup order by class;
>
> sentence problem is:{ order by class}
>
I have PostgreSQL v7.02 in RedHat 6.2;
I have problem with is Query:
select name, 'user' as class from smuser union
select name, 'group' as class from smgroup order by class;
sentence problem is:{ order by class}
thank you,
Christian Gonzalez
[EMAIL PROTECTED] writes:
> I have problem with the GROUP BY
But which is it???
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Christian Gonzalez ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Query Problem!!
Long Description
I have problem with the GROUP BY
Sample Code
select name, 'user' as class from smuser union select name, 'group' as class from
Hello!
I've installed Red Hat Linux in my PC.
Along with the packages I installed Postgresql.
I went through the documentation available and tried to create a database
when I typed the following in the command prompt,
createdb mydatabase
the following error message was flashed:
Connection to datab
Hello
I've found a strange behavior in query execution:
I have really big table fti_author (>4 000 000 records) and i want to
find ID intersection of ones contain '^clarke' and '^arthur'
I've created 2 methods
1 select all with '^clarke' into temp table
select intersection of ones with '^arth
Cool. Thanks, Tom.
> "Rick Smith" <[EMAIL PROTECTED]> writes:
> >PostgreSQL version (example: PostgreSQL-6.5.3) :PostgreSQL-6.5.3
>
> > ERROR: ExecSubPlan: null value returned by expression subselect
>
> 6.5 and old
"Rick Smith" <[EMAIL PROTECTED]> writes:
>PostgreSQL version (example: PostgreSQL-6.5.3) :PostgreSQL-6.5.3
> ERROR: ExecSubPlan: null value returned by expression subselect
6.5 and older don't cope with sub-selects r
POSTGRESQL BUG REPORT TEMPLATE
Your name :Richard Smith
Your email address : [EMAIL P
Robert Berger <[EMAIL PROTECTED]> writes:
> I am running 6.5.3 on a tables with >300,000 rows. I've seen lots of
> cases where queries fail if I haven't done a vacuum analyze; I
> understand this is one of the quirks of PostgreSQl.
You do? It's not a known failure mode to my knowledge --- the qu
I am running 6.5.3 on a tables with >300,000 rows. I've seen lots of
cases where queries
fail if I haven't done a vacuum analyze; I understand this is one of the
quirks of PostgreSQl.
However, below is an example of a query that fails if I HAVE done a
vacuum analyze. Therefore,
I have no way of g
65 matches
Mail list logo
