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
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
"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
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
"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
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
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
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: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
"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 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
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
"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,
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",
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
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
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
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/
> > 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
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
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
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
-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
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.
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 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
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
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
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
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
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
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
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
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
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 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 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.)
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 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
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
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
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
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
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
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.
>
>
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
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
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.
>
>
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
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
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
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
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
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
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
> 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
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
57 matches
Mail list logo
