On Sun, Jan 8, 2012 at 12:35 AM, Darren Duncan wrote:
> Mike Christensen wrote:
According to the manuals, Postgres has smallint (2 byte), integer (4
bytes) and bigint (8 bytes).. I use a lot of structures with "bytes"
in my code and it's kinda annoying to cast DB output from I
Mike Christensen wrote:
According to the manuals, Postgres has smallint (2 byte), integer (4
bytes) and bigint (8 bytes).. I use a lot of structures with "bytes"
in my code and it's kinda annoying to cast DB output from Int16 to
Byte every time, especially since there's no explicit cast in .NET
>> According to the manuals, Postgres has smallint (2 byte), integer (4
>> bytes) and bigint (8 bytes).. I use a lot of structures with "bytes"
>> in my code and it's kinda annoying to cast DB output from Int16 to
>> Byte every time, especially since there's no explicit cast in .NET and
>> you hav
Mike Christensen wrote:
According to the manuals, Postgres has smallint (2 byte), integer (4
bytes) and bigint (8 bytes).. I use a lot of structures with "bytes"
in my code and it's kinda annoying to cast DB output from Int16 to
Byte every time, especially since there's no explicit cast in .NET
According to the manuals, Postgres has smallint (2 byte), integer (4
bytes) and bigint (8 bytes).. I use a lot of structures with "bytes"
in my code and it's kinda annoying to cast DB output from Int16 to
Byte every time, especially since there's no explicit cast in .NET and
you have to use System
"J. Greg Davidson" writes:
> (1) What are the current criteria for when an SQL function called
> within another SQL function will be inlined?
It depends on a number of things, not least which PG version you're
talking about. When in doubt, consult the source code (see
inline_function or inline_s
I've been having some serious (> 100x) slowness in some of my code
which uses nice maintainable little SQL functions versus when I do
the same code as a big messy expression. I got rid of STRICT, I've
tried STABLE and even IMMUTABLE and I can't seem to get the speed
difference to go away, so here
On Fri, Jan 6, 2012 at 10:38 PM, John R Pierce wrote:
> you should check your attitude at the door. this isn't Microsoft Pay per
> Incident Tech Support.
I saw the door. Found some other attitudes that were allowed to be let
in. Like asking me to write my own patch. You see, attitudes come in
I'm considering the migration of an existing large (2.3TB) table to a new
tablespace. The table size, according to the '\dt+' command:
public | city_summary | table | altosresearch | 2345 GB|
Are there any considerations - besides the usual disk and network IO
constraints - that I need to ta
Hey ChoonSoo,
2012/1/6 ChoonSoo Park
> I just wonder if there is a way to program lo client interfaces (lo_creat,
> lo_write, lo_read) in non-blocking mode.
> PQsendQueryParams works perfect for executing a sql command in
> non-blocking mode. But I couldn't find a way for handling large objects.
10 matches
Mail list logo
