Hi all,
I'm trying to do some comparisons between the EXTERNAL and the EXTENDED storage
methods on a bytea column and from the outside the setting doesn't appear to
affect the value stored on initial insert, but perhaps I'm looking at the wrong
numbers. If I create two new tables with a single
On Apr 12, 2011, at 10:33 AM, Bill Moran wrote:
> In response to Joel Stevenson :
>
>> select pg_total_relation_size('obj1') as o1, pg_total_relation_size( (select
>> reltoastrelid from pg_class where relname = 'obj1' ) ) as otoast1,
&
Thanks for the help with that, Noah. Indeed the sizes do look like I'd expect
them to if I force deflation of the bytea value before inserting it into the
EXTENDED column.
On Apr 21, 2011, at 2:02 PM, Noah Misch wrote:
> On Mon, Apr 11, 2011 at 03:19:23PM -0700, Joel Stevens
Hi all,
Does anyone know if temp tables and the operations on them (like inserting or
copying to) are replicated from master to standby servers via the new PG WAL
shipping replication? Given that temp tables are only accessible per-session
it would seem unnecessary but if the shipping is happe
At 10:11 PM +0100 11/6/04, Pierre-Frédéric Caillaud wrote:
explain select notificationID from NOTIFICATION n, ITEM i where
n.itemID = i.itemID;
QUERY PLAN
--
Hash Join (cost=47162.85..7
Buenas tardes, all.
I'm puzzled by my inability to use the following INSERT statement:
INSERT INTO RM_USER VALUES(RM_USER.ID, RM_USER.FIRST_NAME) VALUES(1, 'DUBYA')
it seems that postgres is unhappy about the explicit column naming
(e.g. 'RM_USER.ID' instead of just 'ID') because I end up with
