On 31 Jul 2008, at 10:29AM, Miernik wrote:
Richard Huxton [EMAIL PROTECTED] wrote:
I just installed pgpool2 and whoaaa! Everything its like about 3
times
faster! My application are bash scripts using psql -c UPDATE
Probably spending most of their time setting up a new connection,
On 31 Jul 2008, at 11:17AM, Miernik wrote:
Theo Kramer [EMAIL PROTECTED] wrote:
file `which psql`
/usr/bin/psql: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
stripped
[EMAIL PROTECTED]:~$ file `which psql`
/usr/bin
On 23 Apr 2008, at 9:23AM, Hans Ekbrand wrote:
I cannot understand why the following two queries differ so much in
execution time (almost ten times)
Query A (two queries)
select distinct moment.mid from moment,timecard where parent = 45
and (pid=17 and timecard.mid = moment.mid) order by
On Thu, 2008-03-06 at 12:32 +0530, sathiya psql wrote:
i had a table with 50 lakh record...
it has a column called oid ( obviously all the tables will have
this ), but while doing any operation it is getting slow because of
the number of records...
if i remove the oid column will i get
On Wed, 2008-02-06 at 11:53 +, Simon Riggs wrote:
On Wed, 2008-02-06 at 09:42 +0100, SURANTYN Jean François wrote:
That issue is very annoying because with generated SQL queries (from
Business Objects for example) on big tables, it is possible that some
queries have several times the
On Thu, 2007-10-11 at 16:04 -0400, Merlin Moncure wrote:
On 10/11/07, Andrew - Supernews [EMAIL PROTECTED] wrote:
On 2007-10-10, Theo Kramer [EMAIL PROTECTED] wrote:
When doing a 'manual' prepare and explain analyze I get the following
rascal=# prepare cq (char(12), smallint, integer
On Thu, 2007-10-11 at 13:28 -0400, Merlin Moncure wrote:
On 10/11/07, Theo Kramer [EMAIL PROTECTED] wrote:
On Thu, 2007-10-11 at 10:12 +0100, Richard Huxton wrote:
Theo Kramer wrote:
So I suspect that there is something more fundamental here...
OK, so there must be something
On Thu, 2007-10-11 at 18:28 +, Andrew - Supernews wrote:
On 2007-10-10, Theo Kramer [EMAIL PROTECTED] wrote:
When doing a 'manual' prepare and explain analyze I get the following
rascal=# prepare cq (char(12), smallint, integer) as SELECT oid,
calllog_mainteng, calllog_phase
On Fri, 2007-10-12 at 09:02 -0400, Merlin Moncure wrote:
fwiw, I converted a pretty large cobol app (acucobol) to postgresql
backend translating queries on the fly. if this is a fresh effort,
you definately want to use the row-wise comparison feature of 8.2.
not only is it much simpler, it's
On Thu, 2007-10-11 at 10:12 +0100, Richard Huxton wrote:
Theo Kramer wrote:
So I suspect that there is something more fundamental here...
OK, so there must be something different between the two scenarios. It
can only be one of:
1. Query
2. DB Environment (user, locale, settings
Hi
I have been having some serious performance issues when using prepared
statements which I can not re-produce when using a direct statement. Let
me try to explain
The query does an order by in descending order on several columns for
which an index exists.
The explain output as follows
On Wed, 2007-10-10 at 15:55 -0400, Jonah H. Harris wrote:
On 10/10/07, Theo Kramer [EMAIL PROTECTED] wrote:
When running the query directly from psql it returns the required rows
in less than 100 milli-seconds.
However, when using a prepared statement from my C application on the
above
On Wed, 2006-04-19 at 01:08, Tom Lane wrote:
Theo Kramer [EMAIL PROTECTED] writes:
select * from mytable where
(c1 = 'c1v' and c2 = 'c2v' and c3 = 'c3v') or
(c1 = 'c1v' and c2 'c2v') or
(c1 'c1v')
order by c1, c2, c3;
Yeah ... what you really want is the SQL-spec row
On Wed, 2006-04-19 at 08:00, Theo Kramer wrote:
I tried this on my test system running 8.1.3 and appears to work fine.
Appreciate it if you could let me know in what cases it does not work
properly.
Please ignore - 'Explain is your friend' - got to look at the tips :)
--
Regards
Theo
Hi
Apologies if this has already been raised...
PostgreSQL 8.1.3 and prior versions. Vacuum done.
Assuming a single table with columns named c1 to cn and a requirement to
select from a particular position in multiple column order.
The column values in my simple example below denoted by 'cnv'
On Fri, 2006-03-24 at 12:21, Jim C. Nasby wrote:
On Thu, Mar 23, 2006 at 01:09:49PM +0200, Theo Kramer wrote:
ii If no to i, is it feasible to extend PostgreSQL to allow traversing
an index in column descending and column ascending order - assuming
an order by on more than one column
On Fri, 2006-03-17 at 08:25, [EMAIL PROTECTED] wrote:
I have a performance problem when traversing a table in index order with
multiple columns including a date column in date reverse order. Below
follows a simplified description of the table, the index and the
associated query
\d
On Thu, 2006-03-23 at 16:16, Alvaro Herrera wrote:
Theo Kramer wrote:
All good input - thanks, however, before I start messing with my stuff
which I know will be complex - some questions to any of the developers
on the list.
i Is it feasible to extend index creation to support
Hi
I have a performance problem when traversing a table in index order with
multiple columns including a date column in date reverse order. Below
follows a simplified description of the table, the index and the
associated query
\d prcdedit
prcdedit_prcd | character(20) |
19 matches
Mail list logo
