On Mon, Feb 23, 2009 at 3:56 PM, pi song wrote:
> I think the point that you can access more system cache is right but that
> doesn't mean it will be more efficient than accessing from your local disk.
> Take Hadoop for example, your request for file content will have to go to
> Namenode (file ch
I have written a presentation about the major 8.4 features known so far:
http://momjian.us/main/writings/pgsql/features.pdf
Comments? Suggestions? Please email me offlist and I will update the
PDF.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Sun, Feb 22, 2009 at 5:18 PM, pi song wrote:
> One more problem is that data placement on HDFS is inherent, meaning you
> have no explicit control. Thus, you cannot place two sets of data which are
> likely to be joined together on the same node = uncontrollable latency
> during query processin
Martin Pihlak writes:
> Attached documentation patch attempts to clarify this.
Applied in a slightly modified form.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
One more problem is that data placement on HDFS is inherent, meaning you
have no explicit control. Thus, you cannot place two sets of data which are
likely to be joined together on the same node = uncontrollable latency
during query processing.
Pi Song
On Mon, Feb 23, 2009 at 7:47 AM, Robert Haas
On Sat, Feb 21, 2009 at 9:37 PM, pi song wrote:
> 1) Hadoop file system is very optimized for mostly read operation
> 2) As of a few months ago, hdfs doesn't support file appending.
> There might be a bit of impedance to make them go together.
> However, I think it should a very good initiative to
2009/2/22 Martin Pihlak :
> Pavel Stehule wrote:
>> then documentation is probably little bit wrong (needs some additional
>> comment) . This text specifies using option 'all' for sql functions.
>>
>
> Attached documentation patch attempts to clarify this.
>
> regards,
> Martin
>
>
thank you
Pavel
Pavel Stehule wrote:
> then documentation is probably little bit wrong (needs some additional
> comment) . This text specifies using option 'all' for sql functions.
>
Attached documentation patch attempts to clarify this.
regards,
Martin
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/conf
hi ...
i think the easiest way to do this is to simply add a mechanism to
functions which allows a function to "stream" data through.
it would basically mean losing join support as you cannot "read data
again" in a way which is good enough good enough for joining with the
function providing
2009/2/22 Tom Lane :
> Pavel Stehule writes:
>> postgres=# create or replace function test1(i integer) returns int as
>> $$ select $1; $$ language sql;
>
> This function will get inlined, so there's no separate entity to track
> the execution of.
>
then documentation is probably little bit wrong
Hi.
Sorry late reaction.
I try check of CVS-HEAD now.
$ make check NO_LOCALE=true
...
===
All 120 tests passed.
===
However, same action as Inou-sane is seen.
make check MULTIBYTE=euc_jp NO_LOCALE=true
The differences that caused some tests to fail can
Peter Eisentraut writes:
> The feof(stdin) test is there from a time when the prompt when to stdout
> and the input came from stdin. Now it would usually not have any effect
> unless the program reads from stdin before connecting to the database,
> which doesn't happen, as far as I can tell.
Pavel Stehule writes:
> postgres=# create or replace function test1(i integer) returns int as
> $$ select $1; $$ language sql;
This function will get inlined, so there's no separate entity to track
the execution of.
regards, tom lane
--
Sent via pgsql-hackers mailing li
Hello
I am checking this functionality and I am afraid, so option all is broken.
postgres=# select * from pg_stat_user_functions; funcid | schemaname
| funcname | calls | total_time | self_time
++--+---++---
24608 | public | test |
Mohsen Alimomeni writes:
> Hi,
> To implement my local calendar, I tried adding a new type (pdate) to pgsql
> as an extension. At first I used a struct of size 6, and I returned a
> pointer to it in pdate_in with no problem. Now I changed the type to int32,
> returning PG_RETURN_INT32. I removed
Hi,
To implement my local calendar, I tried adding a new type (pdate) to pgsql
as an extension. At first I used a struct of size 6, and I returned a
pointer to it in pdate_in with no problem. Now I changed the type to int32,
returning PG_RETURN_INT32. I removed all palloc calls. but the server
cras
The series of SE-PostgreSQL patches for v8.4 are updated:
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1590.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1590.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4d
17 matches
Mail list logo
