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
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 pa
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 c
"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 inste
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 pgsql-hac
As you can see here:
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=jaguar&br=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, w
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)
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 c
"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
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 postgre
[EMAIL PROTECTED] writes:
> As you can see here:
> http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=jaguar&br=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
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 encrypt
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 pr
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:
> *
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 accessib
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 ke
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 jagua
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 th
27 matches
Mail list logo
