Why not simply,
SELECT * FROM xxx WHERE timestamp_column::date = '2008-05-20'::date;
Στις Thursday 19 June 2008 21:56:09 ο/η Roberto Garcia έγραψε:
We changed it because 8.3 doesn't allow the operator LIKE on timestamp
columns. Your syntax works fine but we weren't used to use as u do.
There
Hi,
I wonder why pgAdmin's query tool can't process the COPY commands generated by
a BACKUP (pg_dump) in plain text dumps (COPY table (column1, column2) FROM
stdin). Is it just that it's from standard input? Is there a way to make it
work?
Thank you very much,
Peter
--
GMX startet
On Thu, 2008-06-19 at 19:31 -0400, Bhella Paramjeet-PFCW67 wrote:
We have created a postgres database with a warm-standby in postgres 8.2
following the document on the archive by Charles Duffy.
Please can you read the main docs? The above document is out of date.
If there is something not
I got curious and did a few tests on a 8.3.3 database on my laptop.
The 3 different queries all worked, but one took twice as long.
The table alarmlogg has ~93 rows, query returns ~26 rows.
Column alarm_tid is timestamp with time zone.
There is an index on alarm_tid.
select * from
Στις Friday 20 June 2008 16:26:19 ο/η Roberto Garcia έγραψε:
We have an index on the time_stamp column, if the format of argument is
different from the format the index was created it is not used, then
performance is decreased because a sequential scan is done instead of an
index scan.
Then
On Thu, Jun 19, 2008 at 6:31 PM, in message
[EMAIL PROTECTED],
Bhella
Paramjeet-PFCW67 [EMAIL PROTECTED] wrote:
we need to monitor the standby database to
check that it is up, it is getting synced every 10 minutes, and that
it
is not out of sync with primary database. What would be the
Curiosity is good, I also did some tests here, with yours and the syntax
suggested by Achilleas Mantzios and the results were:
1ST TEST
Jan-Ivar Mellingen [EMAIL PROTECTED] writes:
I got curious and did a few tests on a 8.3.3 database on my laptop.
The 3 different queries all worked, but one took twice as long.
SELECT * FROM alarmlogg WHERE alarm_tid = CAST('2007-05-20' as
timestamp) AND alarm_tid CAST('2008-05-21' as
Joshua D. Drake wrote:
Tena Sakai wrote:
Hi everybody,
I am running postgres 8.3.0 on linux (hardware is dell).
When I issue: cat /etc/redhat-release
It comes back with: Red Hat Enterprise Linux AS release 4 (Nahant
Update 4)
and when I issue: uname -r
It says: 2.6.9-42.ELsmp
Given that,
There goes my breakfast...
pg_dump: ERROR: missing chunk number 0 for toast value 110439697
pg_dump: SQL command to dump the contents of table attachments failed:
PQendcopy() failed.
pg_dump: Error message from server: ERROR: missing chunk number 0 for toast
value 110439697
pg_dump: The command
Scott Whitney [EMAIL PROTECTED] writes:
There goes my breakfast...
pg_dump: ERROR: missing chunk number 0 for toast value 110439697
pg_dump: SQL command to dump the contents of table attachments failed:
PQendcopy() failed.
pg_dump: Error message from server: ERROR: missing chunk number 0
We have an index on the time_stamp column, if the format of argument is
different from the format the index was created it is not used, then
performance is decreased because a sequential scan is done instead of an
index scan.
Achilleas Mantzios wrote:
Why not simply,
SELECT * FROM xxx WHERE
Tom,
Thanks. Here's the output of what just happened:
rt3=# select reltoastrelid::regclass from pg_class where relname =
'attachments';
reltoastrelid
---
pg_toast.pg_toast_8507627
(1 row)
rt3=# reindex table pg_toast.pg_toast_8507627;
REINDEX
rt3=# \q
On Jun 19, 2008, at 8:13 AM, Carol Walter wrote:
I just did an upgrade from 8.1 to 8.2.3. We'll go up to 8.3.3 very
soon, but for reasons I won't go into, this intermediate step was
necessary. My problem is, now that the upgrade is done, how can I
clean up the database from the old
Well, I was unable to fix this with any reindexing stuff. Rather than use
last night's pg_dump, which completed successfully, and lose today's data,
however, I did this:
a) dump the schema
b) dump each individual table minus my bad one
c) select all the recs except the bad one
c1) I found this
15 matches
Mail list logo
