Hello,
So, I embarked (yesterday) on a weekend project to add a new feature to
Postgres...
I use PHP with persistent connections and always have been bothered that
those very small AJAX queries (usually simple selects returning 1 row)
take more CPU in postgres to parse plan than
PFC wrote:
Hello,
So, I embarked (yesterday) on a weekend project to add a new
feature to Postgres...
I use PHP with persistent connections and always have been
bothered that those very small AJAX queries (usually simple selects
returning 1 row) take more CPU in postgres to parse
On Fri, Mar 28, 2008 at 2:04 PM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
I think the creation of minimal_tuple in the middle is a overhead which
can
be avoided by creating a mem-map and directly creating the minimal_tuple
in
the
PFC wrote:
Hello,
So, I embarked (yesterday) on a weekend project to add a new
feature to Postgres...
I use PHP with persistent connections and always have been bothered
that those very small AJAX queries (usually simple selects returning 1
row) take more CPU in postgres to
Brendan Jurd wrote:
1. describe malloc's the cells to zero, but print just does a local
calloc without any initialisation.
Um, calloc is the same as malloc + zero. Those two seem identical to me.
2. describe only does an mbvalidate for WIN32, but print does it in all cases.
There's this
Brendan Jurd [EMAIL PROTECTED] writes:
So, it looks like:
1. describe malloc's the cells to zero, but print just does a local
calloc without any initialisation.
There isn't any functional difference there. I am not sure, but I think
the reason print.c has its own malloc wrappers instead of
On 31/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
There isn't any functional difference there. I am not sure, but I think
the reason print.c has its own malloc wrappers instead of depending on
common.c's is that we use print.c in some bin/scripts/ programs that
do not want common.c too.
Neil Conway [EMAIL PROTECTED] writes:
Applied to HEAD.
At this point it would probably be a good idea if a couple of buildfarm
machines were to start testing builds with --disable-integer-datetimes
... any volunteers out there?
regards, tom lane
--
Sent via
As you can see here:
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=jaguarbr=HEAD
Jaguar has been failing for two days while centaur is ok.
The only diff is that jaguar is compiling with -DCLOBBER_CACHE_ALWAYS
Is that related?
Thought you should know.
Regards
--
Olivier PRENANT
Here is the result of my little experiment, for your viewing pleasure,
lol.
Now it works. Well, it hasn't crashed yet... so I guess I can show it to
people ;)
- Purpose :
Allow PHP (or other languages) users to use prepared statements
(pg_exec()) together with persistent connections,
Andrew Gilligan [EMAIL PROTECTED] writes:
I've attached an updated patch (based on 8.3RC2) that adds the ACL
information to \l and the size to \l+ if available.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Folks,
I'd like to take a whack at making set-returning functions returning
SETOF RECORD a little more fun to use. Let's imagine that we have a
table foo and a function returning SETOF RECORD that can return foos.
The call might look something like:
SELECT a, b, c
FROM f(ROW OF foo)
WHERE ...;
Hello All,
I would like to submit following feature request for Postgres:
1. Transparent Data Encryption: The column which needs to be stored in
encrypted form can be specified through DDL. The encryption key can be stored
in a secure file accessible through a pass phrase. That particular
Sibte Abbas [EMAIL PROTECTED] writes:
On 9/9/07, Sibte Abbas [EMAIL PROTECTED] wrote:
Attached is the patch for the TODO item mentioned at
http://archives.postgresql.org/pgsql-hackers/2007-09/msg00352.php
I looked this over and realized that it has little to do with the
functionality that was
PFC wrote:
PFC wrote:
Hello,
So, I embarked (yesterday) on a weekend project to add a new
feature to Postgres...
I use PHP with persistent connections and always have been
bothered that those very small AJAX queries (usually simple selects
returning 1 row) take more CPU in
[EMAIL PROTECTED] writes:
As you can see here:
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=jaguarbr=HEAD
Jaguar has been failing for two days while centaur is ok.
I asked you to look into that yesterday
http://archives.postgresql.org/pgsql-hackers/2008-03/msg01216.php
The copy of
Hello
maybe I don't understand well your idea. There exist simple syntax -
table function
http://archives.postgresql.org/pgsql-patches/2007-02/msg00341.php
and it is standard
regards
Pavel Stehule
On 30/03/2008, David Fetter [EMAIL PROTECTED] wrote:
Folks,
I'd like to take a whack at
On Sun, Mar 30, 2008 at 10:00:33PM +0200, Pavel Stehule wrote:
Hello
maybe I don't understand well your idea. There exist simple syntax -
table function
http://archives.postgresql.org/pgsql-patches/2007-02/msg00341.php
and it is standard
It's completely different from your patch, which
sanjay sharma [EMAIL PROTECTED] writes:
1. Transparent Data Encryption: The column which needs to be stored in
encrypted form can be specified through DDL. The encryption key can be stored
in a secure file accessible through a pass phrase. That particular column
would apper in encrypted
PFC [EMAIL PROTECTED] writes:
Here is the result of my little experiment, for your viewing pleasure,
I'm having a problem with the terminology here, since AFAICT what your
patch does is exactly not a global prepare --- there is no permanently
stored cached plan. That's a good thing
Joris Dobbelsteen [EMAIL PROTECTED] writes:
The MAJOR benefit of Microsoft's approach is that it works on existing
application, and, most importantly makes NO assumptions on the
volatile server state. A few cases where the Microsoft solution works,
while yours will fail is:
* Server
On Sun, Mar 30, 2008 at 4:36 PM, Tom Lane [EMAIL PROTECTED] wrote:
sanjay sharma [EMAIL PROTECTED] writes:
1. Transparent Data Encryption: The column which needs to be stored in
encrypted form can be specified through DDL. The encryption key can be stored
in a secure file accessible
On Sun, Mar 30, 2008 at 2:52 PM, sanjay sharma [EMAIL PROTECTED] wrote:
1. Transparent Data Encryption: The column which needs to be stored in
encrypted form can be specified through DDL.
Hey Sanjay. Based on your wording, you've probably used Oracle's TDE
and want to implement it in PG.
Kevin Hunter [EMAIL PROTECTED] writes:
At 3:50p -0400 on Sat, 29 Mar 2008, Tom Lane wrote:
The code appears to want 700 and ownership equal to that of the
process executing libpq, ie, the apache server.
I just checked the 8.3 documentation and didn't see any mention of
the private key file
Hey Jonah,
You are correct. I have worked with oracle for a long time and only recently
started working with Postgres. I am quite satisfied that Postgres is able to
deliver me most of the features/ services which Oracle used to deliver but at
much reduced cost.This is very helpful in pushing
I wrote:
[EMAIL PROTECTED] writes:
The only diff is that jaguar is compiling with -DCLOBBER_CACHE_ALWAYS
Is that related?
Hmm, that might be the needed clue --- thanks for the reminder.
Yup, that was it --- was able to duplicate the problem with
-DCLOBBER_CACHE_ALWAYS. So I think jaguar's
Well, it's the end of March, and I'm already starting to feel like we've
been commit-festing forever :-(. At this point I see only one remaining
patch that seems likely to go in without any further discussion --- that's
Pavel's plpgsql EXECUTE USING thing. However, we've got boatloads of
stuff
27 matches
Mail list logo
