On 24 May 2014, at 8:21, David Noel wrote:
> COPY (SELECT * FROM page WHERE "PublishDate" between '2014-03-01' and
> '2014-04-01') TO
> '/home/ygg/sql/backup/pagedump.2014-03-01.to.2014-04-01.copy';
>
> gives me:
>
> ERROR: could not open file
> "/home/ygg/sql/backup/pagedump.2014-03-01.to.201
I posted this question on dba.se (http://dba.stackexchange.com/q/65821/1396)
and was advised to try asking here.
If I'm using the Data Checksum feature (new to 9.3:
https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.3#Data_Checksu
ms), and in the event of a checksum failure on a repl
David Noel wrote
> COPY (SELECT * FROM page WHERE "PublishDate" between '2014-03-01' and
> '2014-04-01') TO
> '/home/ygg/sql/backup/pagedump.2014-03-01.to.2014-04-01.copy';
Is /home/ygg a client or server path?
COPY != \copy
David J.
--
View this message in context:
http://postgresql.104569
Hi
Please forgive this question if it is naïve.
Would the following be practical to implement:
A btree-like index type that points to *pages* rather than individual rows.
Ie if there are many rows in a page with the same data (in the indexed
columns), only one index entry will exist. In
On Sat, May 24, 2014 at 05:58:37PM +0100, Jack Douglas wrote:
> Would the following be practical to implement:
> A btree-like index type that points to *pages* rather than individual rows.
> Ie if there are many rows in a page with the same data (in the indexed
> columns), only one index entry wil
Martijn van Oosterhout writes:
> On Sat, May 24, 2014 at 05:58:37PM +0100, Jack Douglas wrote:
>> Would the following be practical to implement:
>> A btree-like index type that points to *pages* rather than individual rows.
> It's an interesting idea, but, how can you *ever* delete index entries?
I got it fella's, thanks. It was a really simple oversight on my part.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general