Hi, dbalinglung.
You are probably confusing types oid and lo or bytea. There's no way you
could put a image into oid column. I'm using bytea type without problems.
Also check "bytea as lo" checkbox in ODBC dialog (if you use ODBC). Also
TDBImage is no good if you want to use jpg files. I found
Dear Expert,
I'm sorry for my newbie question, I have a dificulty to load image file from
field OID type on PostgreSQL with Borland Delphi 7.
I would like to showing image file with TDBImage component to Delphi Form, but
the image file can't display, any sugestion for me about how can i do to
2008/12/30 Christian Schröder
> Hi list,
> in our PostgreSQL 8.2.9 database I have these tables:
>
> create table table1 (
> key1 char(12),
> key2 integer,
> primary key (key1, key2)
> );
>
> create table table2 (
> key1 char(12),
> key2 integer,
> key3 v
Hi list,
in our PostgreSQL 8.2.9 database I have these tables:
create table table1 (
key1 char(12),
key2 integer,
primary key (key1, key2)
);
create table table2 (
key1 char(12),
key2 integer,
key3 varchar(20),
primary key (key1, key2, ke
On Monday 29 December 2008 11:28:13 am Rob Richardson wrote:
> Greetings!
>
> A customer reported an error generated by our database. However, many
> of our functions have errors in RAISE EXCEPTION statements, in which the
> % character was omitted. The error message the customer saw was
> compla
Greetings!
A customer reported an error generated by our database. However, many
of our functions have errors in RAISE EXCEPTION statements, in which the
% character was omitted. The error message the customer saw was
complaining that there were too many arguments to a RAISE statement. We
were
- Original Message -
From: "Terry Lee Tucker"
To:
Sent: Monday, December 29, 2008 5:57 AM
Subject: Re: [GENERAL] open transaction?
On Monday 29 December 2008 06:48, blackwater dev wrote:
I just logged into postgres from the command line and did:
begin:
select blah;
select blah;
On Mon, Dec 29, 2008 at 9:28 AM, Scott Ribe wrote:
>> voila! cache dumped.
>
> What about read caches in the disk devices themselves?
Given that most drives have caches that are in the 16 to 32Meg range,
I doubt it makes a big difference. But you can always just dd a file
both ways that are 100
> voila! cache dumped.
What about read caches in the disk devices themselves?
--
Scott Ribe
scott_r...@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.post
On Mon, Dec 29, 2008 at 8:36 AM, Scott Ribe wrote:
> Creating the partial index reads rows, and the pages are left in the disk
> cache. The only way to do proper comparisons is to reboot between trials in
> order to compare queries with cold caches, or use the latter of multiple
> runs in order to
> The WHERE condition can be divided into a "slowly changing" part and in
> a "random" one. The random part is the one I change at every query to avoid
> result caching.
The first query will leave in cache at least many of the index pages needed
by the second query, and likely actual rows needed b
On Mon, Dec 29, 2008 at 7:41 AM, Reg Me Please wrote:
> Hi.
>
> The WHERE condition can be divided into a "slowly changing" part and in
> a "random" one. The random part is the one I change at every query to avoid
> result caching.
>
> The planner seems to be smart enough to "learn" while working
Hi.
The WHERE condition can be divided into a "slowly changing" part and in
a "random" one. The random part is the one I change at every query to avoid
result caching.
The planner seems to be smart enough to "learn" while working but then
I should see a change in the EXPLAIN output, which never h
Not sure if this applies to your case, but I've seen cases where an initial run
of a particular query is a lot slower than subsequent runs even though no
changes were made between the two. I suspect that the initial run did all the
disk IO needed to get the data (slow), and that the subsequent
HI all.
I have a 8M+ rows table over which I run a query with a and-only WHERE
condition.
The table has been periodically VACUUMed and ANALYZEd.
In the attempt of speeding that up I added a partial index in order to limit
the size of the index. Of course that index is modeled after a "slowly
var
On Monday 29 December 2008 06:48, blackwater dev wrote:
> I just logged into postgres from the command line and did:
>
> begin:
>
> select blah;
> select blah;
>
> \q
>
> Without thinking I closed by connection before committing or rolling back
> my transaction. Did postgres handle this for me? H
Hello
maybe you have autocommit on
try
[pa...@localhost ~]$ psql postgres
psql (8.4devel)
Type "help" for help.
postgres=# \set
AUTOCOMMIT = 'on'
PROMPT1 = '%/%R%# '
PROMPT2 = '%/%R%# '
regards
Pavel Stehule
2008/12/29 Raymond O'Donnell :
> On 29/12/2008 11:53, Raymond O'Donnell wrote:
>> On
Karsten Hilbert wrote:
> On Tue, Dec 23, 2008 at 06:45:17PM -0300, Alvaro Herrera wrote:
> > Hmm, isn't client_encoding reported in the startup packet sent by the
> > server, after auth?
>
> That would not quite be enough -- I am talking about
> messages reported *during* auth, say
>
> FAT
On 29/12/2008 11:53, Raymond O'Donnell wrote:
> On 29/12/2008 11:48, blackwater dev wrote:
>
>> Without thinking I closed by connection before committing or rolling
>> back my transaction. Did postgres handle this for me? How do I see if
>> the transaction is still open?
>
> I'm reasonably sure
On 29/12/2008 11:48, blackwater dev wrote:
> Without thinking I closed by connection before committing or rolling
> back my transaction. Did postgres handle this for me? How do I see if
> the transaction is still open?
I'm reasonably sure that the transaction will get rolled back if the
connect
I just logged into postgres from the command line and did:
begin:
select blah;
select blah;
\q
Without thinking I closed by connection before committing or rolling back my
transaction. Did postgres handle this for me? How do I see if the
transaction is still open?
Thanks!
and in different PGDATA dirs.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
22 matches
Mail list logo
