On Sat, Jul 05, 2008 at 07:04:29PM +0900, H.Harada wrote:
> Hi,
>
> As I proposed a month before, I am working on window function.
> Although this work is at quite early step, I would like to introduce
> it since a part of it have been finished. If you can afford and are
> interested in it, please
> On Wed, Jul 16, 2008 at 01:57:04PM +0900, Tatsuo Ishii wrote:
> > > > No idea. What do you think if we allow only one query name at the
> > > > moment.
> > >
> > > I'm not sure I understand what that has to do with sorting.
> > >
> > > Please find attached a place where I've found some problem
2008/7/17 David Fetter <[EMAIL PROTECTED]>:
> On Sat, Jul 05, 2008 at 07:04:29PM +0900, H.Harada wrote:
>> Hi,
>>
>> As I proposed a month before, I am working on window function.
>> Although this work is at quite early step, I would like to introduce
>> it since a part of it have been finished. If
The patch store hash code only in the index tuple.
It based on Neil Conway's patch with an old version of PostgreSQL.
It passes the regression test but I didn't test the performance yet.
Anyone interested can make a performance test;-)
You can undefine the macro HASHVALUE_ONLY in hash.h to get the
Hi,
Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
Yoshiyuki Asaba and minor corrections by Tatsuo Ishii. (David Fetter's
psql help patches are not included. It seems his git repository has
gone).
This version implements:
- detect certain queries those are not valid acrod
Am 16.07.2008 um 20:38 schrieb David E. Wheeler:
The trouble is that, right now:
template1=# select regexp_replace( 'fxx'::citext, 'X'::citext, 'o');
regexp_replace
fxx
(1 row)
So there's an inconsistency there. I don't know how to make that
work case-insensitively.
Would
Hello
I found
http://mirror.fslutd.org/postgresql/projects/pgFoundry/hashdistinct/pg-hashdistinct.diff
project. Is this project living?
Have somebody plan work on it?
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On Thu, Jul 17, 2008 at 7:38 AM, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> I found
> http://mirror.fslutd.org/postgresql/projects/pgFoundry/hashdistinct/pg-hashdistinct.diff
> project. Is this project living?
This was a SoC project from a couple years ago. It probably wouldn't
take too much to
2008/7/17 Jonah H. Harris <[EMAIL PROTECTED]>:
> On Thu, Jul 17, 2008 at 7:38 AM, Pavel Stehule <[EMAIL PROTECTED]> wrote:
>> I found
>> http://mirror.fslutd.org/postgresql/projects/pgFoundry/hashdistinct/pg-hashdistinct.diff
>> project. Is this project living?
>
> This was a SoC project from a co
Tom Lane wrote:
> There's a fairly interesting crash here:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jaguar&dt=2008-07-16%2003:00:02
> The buildfarm was nice enough to provide a stack trace at the bottom of
> the page, which shows clearly that autovac tried to pfree a null
> pointer.
>
>
On Thu, Jul 17, 2008 at 5:26 AM, Xiao Meng <[EMAIL PROTECTED]> wrote:
> The patch store hash code only in the index tuple.
> It based on Neil Conway's patch with an old version of PostgreSQL.
> It passes the regression test but I didn't test the performance yet.
> Anyone interested can make a perf
Bruce Momjian wrote:
> Log Message:
> ---
> Add column storage type to psql \d+ display.
I think this patch has caused this new warning in psql:
/pgsql//source/00head/src/bin/psql/describe.c: In function
‘describeOneTableDetails’:
/pgsql//source/00head/src/bin/psql/describe.c:832: warnin
Tom Lane wrote:
> There's a fairly interesting crash here:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jaguar&dt=2008-07-16%2003:00:02
> The buildfarm was nice enough to provide a stack trace at the bottom of
> the page, which shows clearly that autovac tried to pfree a null
> pointer.
>
>
Alvaro Herrera wrote:
> Anyway, I propose this patch in HEAD to close this hole. For 8.3 I'm
> thinking in just rearranging the get_*_name calls and adding the goto.
> Thoughts?
Sorry, really attached.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQ
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What I think happened was that the table that was selected to be
>> autovacuumed got dropped during the setup steps, leading get_rel_name()
>> to return NULL at line 2167. vacuum() itself would have fallen out
>> silently ... however
On Thu, Jul 17, 2008 at 06:40:25PM +0900, Tatsuo Ishii wrote:
> Hi,
>
> Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
> Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
I tried this patch vs. CVS HEAD used my usual configure option with
only --with-prefix set, then
Moving to -general. -hackers is for discussion about PG development.
On Jul 16, 2008, at 1:10 AM, cinu wrote:
Hi All, I installed PostgreSQL-8.3.1 on my Suse Linux machine
You should upgrade; I'm pretty sure 8.3 is up to 8.3.3 now.
, it went on fine without any problems and I was able to cre
Xiao Meng escribió:
> The patch store hash code only in the index tuple.
> It based on Neil Conway's patch with an old version of PostgreSQL.
> It passes the regression test but I didn't test the performance yet.
> Anyone interested can make a performance test;-)
> You can undefine the macro HASHV
On Jul 17, 2008, at 03:45, Michael Paesold wrote:
Wouldn't it be possible to create a variant of regexp_replace, i.e.
regexp_replace(citext,citext,text), which would again lower-case the
first two arguments before passing the input to
regexp_replace(text,text,text)?
Sure, but then you end
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I'm having a hard time reproducing this problem; I added a pg_usleep()
> > just before get_rel_name to have the chance to drop the table, but
> > strangely enough it doesn't return NULL. It seems that the cache entry
> > is not getti
On Thu, Jul 17, 2008 at 12:42 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> I think having the HASHVALUE_ONLY define is not a good idea -- it just
> makes the patch harder to read. I suggest just removing the old code
> and putting the new code in place. (That's why we have revision
> control.)
On Thu, Jul 17, 2008 at 12:42:39PM -0400, Alvaro Herrera wrote:
> Xiao Meng escribi?:
> > The patch store hash code only in the index tuple.
> > It based on Neil Conway's patch with an old version of PostgreSQL.
> > It passes the regression test but I didn't test the performance yet.
> > Anyone in
On Thu, Jul 17, 2008 at 02:00:07PM -0400, Jonah H. Harris wrote:
> On Thu, Jul 17, 2008 at 1:54 PM, Kenneth Marshall <[EMAIL PROTECTED]> wrote:
> >> I think having the HASHVALUE_ONLY define is not a good idea -- it just
> >> makes the patch harder to read. I suggest just removing the old code
> >>
On Thu, Jul 17, 2008 at 1:54 PM, Kenneth Marshall <[EMAIL PROTECTED]> wrote:
>> I think having the HASHVALUE_ONLY define is not a good idea -- it just
>> makes the patch harder to read. I suggest just removing the old code
>> and putting the new code in place. (That's why we have revision
>> cont
Kenneth Marshall escribió:
> On Thu, Jul 17, 2008 at 12:42:39PM -0400, Alvaro Herrera wrote:
> > I think having the HASHVALUE_ONLY define is not a good idea -- it just
> > makes the patch harder to read. I suggest just removing the old code
> > and putting the new code in place. (That's why we h
At 2008-07-15 20:28:39 +0530, [EMAIL PROTECTED] wrote:
>
> > I doubt we'd consider accepting a patch done this way.
>
> Yes, it's much too ugly to live.
Though I must say it would have been even MORE horrible to copy all this
code into the backend to make pg_get_functiondef(), notwithstanding the
On Thu, Jul 17, 2008 at 5:26 AM, Xiao Meng <[EMAIL PROTECTED]> wrote:
> The patch store hash code only in the index tuple.
> It based on Neil Conway's patch with an old version of PostgreSQL.
> It passes the regression test but I didn't test the performance yet.
> Anyone interested can make a perf
On Thu, Jul 17, 2008 at 04:24:28PM -0400, Jonah H. Harris wrote:
> On Thu, Jul 17, 2008 at 5:26 AM, Xiao Meng <[EMAIL PROTECTED]> wrote:
> > The patch store hash code only in the index tuple.
> > It based on Neil Conway's patch with an old version of PostgreSQL.
> > It passes the regression test b
Alvaro Herrera wrote:
> Patches for 8.3 and HEAD attached.
And applied.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
Magnus Hagander wrote:
> LIBRARY should match the name of the DLL file. LIBECPGD is the debugging
> version, which is the one linked against the debugging version of the
> runtime. It needs to exist in any case where CRT pointers (FILE*,
> va_args, things like that) is passed between DLLs. If one
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> Though I must say it would have been even MORE horrible to copy all this
> code into the backend to make pg_get_functiondef(), notwithstanding the
> extra utility of a generally-callable function.
FWIW, I just found myself forced to invent pg_get_fun
I am attaching a patch to eliminate duplicate b64_encode and decode
functions from pgcrypto, and to expose those functions for use by
add-ins (I want to use them in Veil).
The patch was made against CVS head today. It compiles and tests
successfully. Though I was unable to run pgrypto regression
On Thu, 2008-07-17 at 16:24 -0400, Jonah H. Harris wrote:
> I'm not really seeing any performance improvements over b-tree.
I'd like to see a theoretical analysis on the benefit case before we
spend too many teraflops on investigation.
In which cases do we expect that hash indexes will beat btre
I've been working on the TABLE-function patch, and I am coming to the
conclusion that it's really a bad idea for plpgsql to not associate
variables with output columns --- that is, I think we should make
RETURNS TABLE columns semantically just the same as OUT parameters.
Here are some reasons:
1.
-Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Simon Riggs
> Sent: Thursday, July 17, 2008 4:10 PM
> To: Jonah H. Harris
> Cc: Xiao Meng; pgsql-hackers@postgresql.org; Kenneth Marshall
> Subject: Re: [HACKERS] [PATCH]-hash index improving
>
>
> On
On Thu, Jul 17, 2008 at 02:11:20PM -0400, Alvaro Herrera wrote:
> Kenneth Marshall escribió:
> > On Thu, Jul 17, 2008 at 12:42:39PM -0400, Alvaro Herrera wrote:
>
> > > I think having the HASHVALUE_ONLY define is not a good idea --
> > > it just makes the patch harder to read. I suggest just remo
On Thu, Jul 17, 2008 at 7:37 PM, Dann Corbit <[EMAIL PROTECTED]> wrote:
>> In which cases do we expect that hash indexes will beat btrees?
>
> Large table unique index equality search should be very fast with hashed
> index (and the only place where any advantage will be seen).
Yes, this is the e
Fixed some off by one errors pointed by Oleg and errors in excluding
overlapping fragments.
Also adding test queries and updating regression tests.
Let me know of any other changes that are needed.
-Sushant.
On Thu, 2008-07-17 at 03:28 +0400, Oleg Bartunov wrote:
> On Wed, 16 Jul 2008, Susha
> > Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
> > Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
>
> I tried this patch vs. CVS HEAD used my usual configure option with
> only --with-prefix set, then tried to make, and got:
>
> make[3]: *** No rule to make tar
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Log Message:
> > ---
> > Add column storage type to psql \d+ display.
>
> I think this patch has caused this new warning in psql:
>
> /pgsql//source/00head/src/bin/psql/describe.c: In function
> ?describeOneTableDetails?:
> /pgsql//source/
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > I think this patch has caused this new warning in psql:
> >
> > /pgsql//source/00head/src/bin/psql/describe.c: In function
> > ?describeOneTableDetails?:
> > /pgsql//source/00head/src/bin/psql/describe.c:832: warning:
> > ?tableinfo.relkind? may
Hi All,
I have been perplexed by random load spikes on an 8.1.11 instance. many
a times they are random, in the sense we cannot tie a particular scenario as
the cause for it! But a few times we can see that when we are executing huge
scripts, which include DDL as well as DML, the load on the b
Just an addition... the strace o/p with selects timing out just runs almost
continuously, it doesn't seem to pause anywhere!
On Fri, Jul 18, 2008 at 9:16 AM, Gurjeet Singh <[EMAIL PROTECTED]>
wrote:
> Hi All,
>
> I have been perplexed by random load spikes on an 8.1.11 instance. many
> a time
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> I don't see that warning with my compiler so I have no way of testing
>> this, but I do see this line pretty high in the function:
>> tableinfo.relkind = *(PQgetvalue(res, 0, 1));
> But it's before the first "goto error_return",
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> During these spikes, in the 'top' sessions we see the 'idle' PG
> processes consuming between 2 and 5 % CPU, and since the box has 8 CPUS (2
> sockets and each CPU is a quad core Intel Xeon processors) and somewhere
> around 200 Postgres processes,
On Fri, Jul 18, 2008 at 9:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> > During these spikes, in the 'top' sessions we see the 'idle' PG
> > processes consuming between 2 and 5 % CPU, and since the box has 8 CPUS
> (2
> > sockets and each CPU is a
On Fri, Jul 18, 2008 at 10:05 AM, Gurjeet Singh <[EMAIL PROTECTED]>
wrote:
> On Fri, Jul 18, 2008 at 9:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>> "Gurjeet Singh" <[EMAIL PROTECTED]> writes:
>> > During these spikes, in the 'top' sessions we see the 'idle' PG
>> > processes consuming betwe
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> Can you please elaborate on what high level diagnosis would you need?
Well, we'd need some idea of which spinlock is being contended for...
> I just ran DROP SCHEMA _ CASCADE; and it spiked again, on a
> very low loaded box!!
That *might* mean that t
On Fri, Jul 18, 2008 at 10:05:33AM +0530, Gurjeet Singh wrote:
> I just ran DROP SCHEMA _ CASCADE; and it spiked again, on a
> very low loaded box!!
Ah, well, if slony is involved, then you have possible locking
problems in the database _also_ to contend with, along with the
spinlock problems. T
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Xiao Meng escribió:
>> You can undefine the macro HASHVALUE_ONLY in hash.h to get the
>> original implementation.
> I think having the HASHVALUE_ONLY define is not a good idea -- it just
> makes the patch harder to read.
While we are griping about read
On Fri, Jul 18, 2008 at 10:21 AM, Andrew Sullivan <[EMAIL PROTECTED]>
wrote:
> On Fri, Jul 18, 2008 at 10:05:33AM +0530, Gurjeet Singh wrote:
>
> > I just ran DROP SCHEMA _ CASCADE; and it spiked again, on a
> > very low loaded box!!
>
> Ah, well, if slony is involved, then you have possible locki
Hello
The core of problems is in standard that doesn't know RETURN NEXT
statement and knows only RETURN TABLE statement - so PL/pgPSM or SQL
doesn't have problem. I am not sure about PL/pgSQL, but I thing so
using TABLE attribs as OUT variables is maybe too simple solution -
there isn't any progre
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> Maybe we can use some well defined implicit record, maybe NEW (or
> RESULT, ROW_RESULT, ROW, TABLE_ROW, ...) like trigger - some like
That sounds like exactly the sort of kluge-solution that I didn't
want to get involved with ...
Anyway, the core feat
On Fri, Jul 18, 2008 at 1:00 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> While we are griping about readability: failure to update the comments
> to match the code is NOT, NOT, NOT acceptable. I had barely started
> to read the patch before encountering this insult to the reader:
> ...
As this is X
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> The real question now has been listed above; why are hash index
> queries, including this patch, no better than b-tree even for straight
> equality comparisons?
Well, the theoretical advantage is that a hash probe is O(1) while a
btree probe is O(log
2008/7/18 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> Maybe we can use some well defined implicit record, maybe NEW (or
>> RESULT, ROW_RESULT, ROW, TABLE_ROW, ...) like trigger - some like
>
> That sounds like exactly the sort of kluge-solution that I didn't
> wan
On Fri, Jul 18, 2008 at 10:41:36AM +0530, Gurjeet Singh wrote:
>
> Just started INIT cluster Slonik command and that spiked too.. for more than
> 10 minutes now!!
Are you attempting to do Slony changes (such as install Slony) on an
active database? I strongly encourage you to read the Slony manu
57 matches
Mail list logo
