On 02 Jul 2014, at 18:55, Arup Rakshit arupraks...@rocketmail.com wrote:
Hi,
I am working on web development project. There I am using this awesome DB.
Let
me tell you first the schema that I am having associated the problem.
I am having a table *users* - which has many fields. Out of
Are you sure this is what you want?
Since there are two columns you will have to either use a CASE or a
sub-select to facilitate calculating the values for each of the columns.
SELECT gender, answer1_avg, answer2_avg
FROM (SELECT DISTINCT gender FROM ...) gn
LEFT JOIN (SELECT gender,
Sandeep, how much effort is it to do this?
On Thu, Jul 3, 2014 at 6:26 AM, Craig Ringer cr...@2ndquadrant.com wrote:
Hi
I've just noticed that the EDB-produced installer for Pg omits a number
of components required to build things that're fully compatible with
libpq if they also use some of
Arup Rakshit wrote
SELECT users.gender,count(*) as participant,
case when daily_action_answers.measure_id = 1 then
avg(daily_action_answers.value) end as cpd,
case when daily_action_answers.measure_id = 2 then
avg(daily_action_answers.value) end as other
FROM users INNER JOIN
Hi
Jacob Bunk Nielsen ja...@bunk.cc writes:
We have a PostgreSQL 9.3.4 running in an LXC container on Debian
Wheezy on a Linux 3.10.43 kernel on a Dell R620 server. Data are
stored on a XFS file system. We are seeing problems such as:
unexpected data beyond EOF in block 2 of relation
Shouldn't be a big deal. Just a change in the installer file and the build
script. Do we want to add all the OpenSSL header files? That must be around
75..
On Thu, Jul 3, 2014 at 1:24 PM, Dave Page dp...@pgadmin.org wrote:
Sandeep, how much effort is it to do this?
On Thu, Jul 3, 2014 at
I think the point is that Craig is asking for the headers and import
libraries for all deps, not just OpenSSL.
On Thu, Jul 3, 2014 at 9:35 AM, Sandeep Thakkar
sandeep.thak...@enterprisedb.com wrote:
Shouldn't be a big deal. Just a change in the installer file and the build
script. Do we want
Okay. For psqlODBC, the dependencies only include gettext and OpenSSL.
On Thu, Jul 3, 2014 at 2:08 PM, Dave Page dp...@pgadmin.org wrote:
I think the point is that Craig is asking for the headers and import
libraries for all deps, not just OpenSSL.
On Thu, Jul 3, 2014 at 9:35 AM, Sandeep
It shouldn't be an issue for psqlODBC itself as users of that link against
the driver manager not the driver. I suspect what Craig is trying to do is
build the driver against our server installation, which means he may need
OpenSSL now, and other dependencies in the future (and don't forget we
unsubscribe pgsql-general@postgresql.org
Hello,
I'm running a postgresql server with version:
# psql --version
psql (PostgreSQL) 9.1.12
What is the correct jdbc driver version for this server?
I'm currently using postgresql-9.2-1002.jdbc4.jar and having some problems
with it and was thinking that maybe i'm using
the wrong driver.
Without commenting on the rest of it...to combine what you show here just
GROUP BY gender and SUM() everything else (i.e., turn the above into a
subquery and then do this)
David J.
Exactly.. I am done. Here is the ORM query :-
def self.employee_learning_by_gender(question_id)
cpd_id
Hi,
I'm getting the following error notifications. It seems to be a problem
with opengeo-server(--I know this list is for postgresql, but I'm hoping
you guys might be able to give me a shove in the right direction):
This is the automatic update system on theServer.serverName.com.
There was a
Hi,
I am working on web development project. There I am using this awesome DB. Let
me tell you first the schema that I am having associated the problem.
I am having a table *users* - which has many fields. Out of them, the one I
need here is *gender*. This column can have value f/m/n.
I have
Can you elaborate as to your problems. That driver should work fine
depending on what you are doing. Also it would be better to use the jdbc
list.
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On 3 July 2014 06:25, Orestis Tsakiridis otsa...@gmail.com wrote:
Hello,
I'm
Hi,
One query is producing the below table :-
answer | count | avg
a1 3 14
a2 2 10
How to convert this to a single row table ?
count | avg_a1 | avg_a2
5 14 10
Regards,
Arup Rakshit
Le 03/07/2014 14:30, Arup Rakshit a écrit :
Hi,
One query is producing the below table :-
answer | count | avg
a1 3 14
a2 2 10
How to convert this to a single row table ?
count | avg_a1 | avg_a2
5 14 10
Regards,
Arup Rakshit
Hi,
Could you
On Thu, Jul 3, 2014 at 8:30 AM, Arup Rakshit arupraks...@rocketmail.com
wrote:
Hi,
One query is producing the below table :-
answer | count | avg
a1 3 14
a2 2 10
How to convert this to a single row table ?
count | avg_a1 | avg_a2
5 14
Hi,
I'm reading code in plpgsql, and I notice that exec_eval_simple_expr() will get
a snapshot for the expr if it is in a VOLATILE function.
Then I try to find out why a snapshot is needed for a expr which has passed
exec_simple_check_plan(). The only reason I could figure out is that maybe
Hi,
Could you have multiple row with same answer ?
If I understand you one row and N + 1 column where N is the number
of answer ?
Regards
You are right. Current it is fixed 2 answer. It means N = 2.
On 07/03/2014 04:30 AM, Augori wrote:
Hi,
I'm getting the following error notifications. It seems to be a problem
with opengeo-server(--I know this list is for postgresql, but I'm hoping
you guys might be able to give me a shove in the right direction):
This is the automatic update system on
Thanks for your quick response.
There are several layers between the application and the JDBC. There is
hibernate ORM and Bitronix transaction manager so it's hard to tell exactly
what causes the problem. It all boils down to this exception (i've tried to
throw out the irrelevant parts).
...
...
Well the JDBC4 bits that are not implemented may or may not be relevant.
You can try the 9.1 driver or even the 9.3 driver. I still don't see enough
information in the stacktrace to tell what the issue really is?
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On 3 July
Hi,
Postgres optimizer automatically tries to convert an IN clause to Hash Join
(something similar to EXISTS equivalent of that query).
Does a similar translation happen for NOT IN as well? Given that the column
used is NOT NUL.
Select * from emp where deptid not in (select deptid from dept
On 07/03/2014 08:35 AM, Sameer Kumar wrote:
Hi,
Postgres optimizer automatically tries to convert an IN clause to Hash
Join (something similar to EXISTS equivalent of that query).
Does a similar translation happen for NOT IN as well? Given that the
column used is NOT NUL.
Select * from
On 7/3/2014 4:01 AM, Arup Rakshit wrote:
Exactly.. I am done. Here is the ORM query :-
def self.employee_learning_by_gender(question_id)
cpd_id = Measure.find_by(option: 'CPD').id
other_id = Measure.find_by(option: 'Others').id
User.select(view.gender, sum(view.participant) as
On Thursday, July 03, 2014 09:04:36 AM John R Pierce wrote:
On 7/3/2014 4:01 AM, Arup Rakshit wrote:
Exactly.. I am done. Here is the ORM query :-
OT, but it boggles my mind that anyone thinks thats 'better' than the
straight SQL
I would like to see your idea. Could you please ? My thick
I try to write this code for postgresql (for mysql working fine):
try
{
m_pRecordset-AddNew();
iTimes++;
VARIANT bitdata[3];
SAFEARRAY *psafe[3] = {NULL, NULL, NULL};
SAFEARRAYBOUND band[3];
I'm running PG 9.3.4 on CentOS 6.4 and noted that backing up my database
takes much longer than restoring it.
That seems counter-intuitive to me because it seems like reading from a
database should generally be faster than writing to it.
I have a database that pg_database_size reports as
On 07/03/14 10:04, David Wall wrote:
A pg_dump backup -- with most of the data stored as large objects --
takes about 5 hours.
If those large objects are 'files' that are already compressed (e.g.
most image files and pdf's) you are spending a lot of time trying to
compress the compressed
On 03/07/14 18:36, Bosco Rama wrote:
On 07/03/14 10:04, David Wall wrote:
A pg_dump backup -- with most of the data stored as large objects --
takes about 5 hours.
If those large objects are 'files' that are already compressed (e.g.
most image files and pdf's) you are spending a lot of time
On Thu, Jul 3, 2014 at 10:04 AM, David Wall d.w...@computer.org wrote:
I'm running PG 9.3.4 on CentOS 6.4 and noted that backing up my database
takes much longer than restoring it.
Are you dumping to a slower disk/storage than the database is using?
What does top -c look like during the dump
Are you sure this is what you want?
Since there are two columns you will have to either use a CASE or a
sub-select to facilitate calculating the values for each of the columns.
SELECT gender, answer1_avg, answer2_avg
FROM (SELECT DISTINCT gender FROM ...) gn
LEFT JOIN (SELECT gender,
On Thursday, July 03, 2014 09:04:36 AM John R Pierce wrote:
On 7/3/2014 4:01 AM, Arup Rakshit wrote:
Exactly.. I am done. Here is the ORM query :-
OT, but it boggles my mind that anyone thinks thats 'better' than the
straight SQL
I would like to see your idea. Could you please ? My thick
On Thu, 03 Jul 2014 10:04:12 -0700
David Wall d.w...@computer.org wrote:
I'm running PG 9.3.4 on CentOS 6.4 and noted that backing up my
database takes much longer than restoring it.
That seems counter-intuitive to me because it seems like reading from
a database should generally be faster
On 7/3/2014 8:24 AM, Arup Rakshit wrote:
OT, but it boggles my mind that anyone thinks thats 'better' than the
straight SQL
I would like to see your idea. Could you please ? My thick brain not able to
produce any straight forward one. Not so good in sql recently..
I was referring to the ORM
On Thursday, July 03, 2014 11:49:04 AM John R Pierce wrote:
On 7/3/2014 8:24 AM, Arup Rakshit wrote:
OT, but it boggles my mind that anyone thinks thats 'better' than the
straight SQL
I would like to see your idea. Could you please ? My thick brain not able
to produce any straight
I'm trying to build a custom background worker for 9.3 in C++. I'm having
trouble getting it running, mostly due to what I think is some weird name
mangling. The code is pretty simple and works fine if I compile it as a C
background worker, but the plan is to link this worker to some other C++
Quinlan Pfiffer quin...@aquameta.com writes:
I'm trying to build a custom background worker for 9.3 in C++.
Recompiling for -fPIC (as it says to) correctly builds the shared library,
but then when I try to run Postgres with my .so file being loaded I get
this:
Hi,
I'm having trouble making sense of the these two autovacuum log entries.
I'm running PostgreSQL 8.4.
[2014-05-22 04:56:43.486 EST] {537cf2c6.30f9} LOG: automatic vacuum of
table postgres.globaldicom.requests: index scans: 1
pages: 0 removed, 163600 remain
tuples: 5916
On Thu, Jul 3, 2014 at 2:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Quinlan Pfiffer quin...@aquameta.com writes:
I'm trying to build a custom background worker for 9.3 in C++.
Recompiling for -fPIC (as it says to) correctly builds the shared
library,
but then when I try to run Postgres
Nick Cabatoff nick.cabat...@gmail.com writes:
I'm having trouble making sense of the these two autovacuum log entries.
I'm running PostgreSQL 8.4.
8.4.what?
It'd probably be a good idea to monitor the counts in pg_stat_all_tables
for the troublesome table(s). I suspect there are a whole lot
Hi Tom,
Thanks for the quick reply. 8.4.9. No db crashes, in fact not even a
restart in May until the 28th. I don't believe any HOT updates were
occurring in that table: all updates modify one or more indexed fields
(update status from pending to done, or update to store a stack trace and
bump
On Fri, Jul 4, 2014 at 7:41 AM, Nick Cabatoff nick.cabat...@gmail.com wrote:
8.4.9.
This has been released in 2011, so you are missing 3 years worth of
bug fixes. It may be a good idea to first update to 8.4.21 before
trying to work more on that (consider as well an upgrade as 8.4 will
be EOL
We've been running 9.2 on our later branches for a while now. We're
overdue to bump the older branches to a later 8.4 though, you're right.
Thanks for the reminder.
On Thu, Jul 3, 2014 at 7:46 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Fri, Jul 4, 2014 at 7:41 AM, Nick Cabatoff
On 7/3/2014 10:36 AM, Bosco Rama wrote:
If those large objects are 'files' that are already compressed (e.g.
most image files and pdf's) you are spending a lot of time trying to
compress the compressed data ... and failing.
Try setting the compression factor to an intermediate value, or even
On 7/3/2014 10:38 AM, Tim Clarke wrote:
I'd also check the effect of those other run components; the vacuum's
and other things that are only running with the backup and not during
the restore.
The vacuumlo, vacuum and analyze run before the pg_dump. I am not
talking about any of the time
On 7/3/2014 4:51 PM, David Wall wrote:
That's interesting. Since I gzip the resulting output, I'll give -Z0
a try. I didn't realize that any compression was on by default.
default compression only happens in with pg_dump -Fc
--
john r pierce 37N 122W
my server is pg 9.1.13 in win8 64, my client is win xp 32 bit, which
odbc version (32 or 64 bit) should be installed in Client ? is
psqlodbc_09_01_0200.zip or psqlodbc_09_01_0200-x64.zip?or others?
thks!
peng
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
my server is pg 9.1.13 in win8 64, my client is win xp 32 bit, which odbc
version (32 or 64 bit) should be installed in Client ? is
psqlodbc_09_01_0200.zip or psqlodbc_09_01_0200-x64.zip?or others?
thks!
peng
when using psqlodbc_09_01_0200.zip,
when i store picture to bytea using vc2008,
calling appendchunk will get com_error.
On 7/4/14, sunpeng blueva...@gmail.com wrote:
my server is pg 9.1.13 in win8 64, my client is win xp 32 bit, which odbc
version (32 or 64 bit) should be installed in Client ?
On 07/03/14 16:51, David Wall wrote:
On 7/3/2014 10:36 AM, Bosco Rama wrote:
If those large objects are 'files' that are already compressed (e.g.
most image files and pdf's) you are spending a lot of time trying to
compress the compressed data ... and failing.
Try setting the compression
On 07/03/14 17:00, John R Pierce wrote:
On 7/3/2014 4:51 PM, David Wall wrote:
That's interesting. Since I gzip the resulting output, I'll give -Z0
a try. I didn't realize that any compression was on by default.
default compression only happens in with pg_dump -Fc
Yeah. OP says he is
El 03/07/14 21:06, sunpeng escribió:
my server is pg 9.1.13 in win8 64, my client is win xp 32 bit, which
odbc version (32 or 64 bit) should be installed in Client ? is
psqlodbc_09_01_0200.zip or psqlodbc_09_01_0200-x64.zip?or others?
thks!
peng
Same as your client, in this case, 32 bits
On 07/03/2014 05:06 PM, sunpeng wrote:
my server is pg 9.1.13 in win8 64, my client is win xp 32 bit, which
odbc version (32 or 64 bit) should be installed in Client ? is
psqlodbc_09_01_0200.zip or psqlodbc_09_01_0200-x64.zip?or others?
thks!
Well if you are installing psqlodbc on the XP
On 07/03/2014 05:10 PM, sunpeng wrote:
when using psqlodbc_09_01_0200.zip,
when i store picture to bytea using vc2008,
calling appendchunk will get com_error.
The actual error message is?
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-general mailing list
On 7/3/2014 5:13 PM, Bosco Rama wrote:
If you use gzip you will be doing the same 'possibly unnecessary'
compression step. Use a similar approach to the gzip command as you
would for the pg_dump command. That is, use one if the -[0-9] options,
like this: $ pg_dump -Z0 -Fc ... | gzip -[0-9]
Why do I get 800A0C93 errors?
If you are getting one of these errors:
ADODB.Recordset error '800a0c93'
Operation is not allowed in this context.
or
I got ADODB.Recordset error '800a0c93'
The operation requested by the application is not allowed in this context.
or
ADODB.Recordset error
On 7/3/2014 5:08 PM, sunpeng wrote:
my server is pg 9.1.13 in win8 64, my client is win xp 32 bit, which
odbc version (32 or 64 bit) should be installed in Client ? is
psqlodbc_09_01_0200.zip or psqlodbc_09_01_0200-x64.zip?or others?
a 32 bit client OS would *mandate* a 32bit ODBC.even on
Thank you, all friends, I will post appendchunk error hresult
800a0c93 to pg_odbc mailing list.
peng
On 7/4/14, John R Pierce pie...@hogranch.com wrote:
On 7/3/2014 5:08 PM, sunpeng wrote:
my server is pg 9.1.13 in win8 64, my client is win xp 32 bit, which
odbc version (32 or 64 bit) should
On 07/03/14 17:30, David Wall wrote:
Bosco, maybe you can recommend a different approach. I pretty much run
daily backups that I only have for disaster recovery. I generally don't
do partials recoveries, so I doubt I'd ever modify the dump output. I
just re-read the docs about formats,
On Thu, Jul 3, 2014 at 11:52 PM, Steve Crawford
scrawf...@pinpointresearch.com wrote:
You can easily test this for yourself using explain.
I tried it out.
NOT EXISTS translates to HASH ANTI JOIN and NOT IN translates to NOT
(HASHED) operation.
Given that the columns used in NOT IN clause
On 7/3/2014 6:26 PM, Bosco Rama wrote:
Hmmm. You are using '--oids' to *include* large objects? IIRC, that's
not the intent of that option. Large objects are dumped as part of a
DB-wide dump unless you request that they not be. However, if you
restrict your dumps to specific schemata and/or
On 07/03/14 21:26, David Wall wrote:
On 7/3/2014 6:26 PM, Bosco Rama wrote:
BTW, is there any particular reason to do the 'split'?
Yes, I transfer the files to Amazon S3 and there were too many troubles
with one really big file.
Is the issue with S3 or just transfer time? I would expect
On 7/3/2014 10:13 PM, Bosco Rama wrote:
Is the issue with S3 or just transfer time? I would expect that
'rsync' with the '--partial' option (or -P if you want progress info
too) may help there.
Don't know if rsync and S3 work together or what that would mean, but
it's not an issue I'm
On 7/3/2014 11:47 AM, Eduardo Morras wrote:
No, there's nothing wrong. All transparent compressed objects stored
in database, toast, lo, etc.. is transparently decompressed while
pg_dump access them and then you gzip it again. I don't know why it
doesn't dump the compressed data directly.
66 matches
Mail list logo
