On Fri, 2007-07-20 at 16:57 -0400, Tom Lane wrote:
> "Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> > What its saying is that there are holds/waits in trying to get locks
> > which are locked at Solaris user library levels called from the
> > postgresql functions:
> > For example both the follo
On Wed, Jul 18, 2007 at 09:13:14PM +0200, Thomas Finneid wrote:
Michael Stone wrote:
I don't understand how the insert you described is table to table?
SELECT INTO is table to table, so is INSERT INTO SELECT FROM.
I could have sworn that at least one of the examples you gave didn't
have any
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> EState is about 8300 bytes,
What?
(gdb) p sizeof(EState)
$1 = 112
This is on a 32-bit machine, but even on 64-bit it wouldn't be more than
double that.
> Would it be worth a special case in the palloc system to avoid having to
> repeatedly issue exter
On Mon, 2007-07-23 at 10:11 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > EState is about 8300 bytes,
>
> What?
>
> (gdb) p sizeof(EState)
> $1 = 112
>
> This is on a 32-bit machine, but even on 64-bit it wouldn't be more than
> double that.
>
> > Would it be worth a sp
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I looked at this last May and my notes say "ExecutorState". I guess that
> was wrong, but my analysis showed there was a single malloc of 8228
> bytes happening once per query during my tests.
Well, if you can track down where it's coming from, we could
On Mon, 2007-07-23 at 10:54 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > I looked at this last May and my notes say "ExecutorState". I guess that
> > was wrong, but my analysis showed there was a single malloc of 8228
> > bytes happening once per query during my tests.
>
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Well, I discover there is an allocation of 8232 (inflation...) made once
> per statement by a memory context called... ExecutorState. Still not
> sure exactly which allocation this is, but its definitely once per
> statement on pgbench, which should narro
Hello all,
how to build an multicolumn index with one column order ASCENDING and
another column order DESCENDING?
The use case that I have is that I use 2 column index where the first
column is kind of flag and the second column is an actual ordering
column. The flag should be always ordered DESC
valgog <[EMAIL PROTECTED]> writes:
> how to build an multicolumn index with one column order ASCENDING and
> another column order DESCENDING?
Use 8.3 ;-)
In existing releases you could fake it with a custom reverse-sorting
operator class, but it's a pain in the neck to create one.
On Jul 23, 7:00 pm, [EMAIL PROTECTED] (Tom Lane) wrote:
> valgog <[EMAIL PROTECTED]> writes:
> > how to build an multicolumn index with one column order ASCENDING and
> > another column order DESCENDING?
>
> Use 8.3 ;-)
>
> In existing releases you could fake it with a custom reverse-sorting
> oper
the manual somewhere states "... if archiving is enabled..." To me
this implies that archiving can be disabled. However I cannot find
the parameter to use to get this result. Or should I enable archiving
and use a backup script like
#!/usr/bin/bash
exit 0
Would appreciate a hint. And yes
Paul van den Bogaard wrote:
> the manual somewhere states "... if archiving is enabled..." To me this
> implies that archiving can be disabled. However I cannot find the parameter
> to use to get this result.
Archiving is disabled by not setting archive_command.
--
Alvaro Herrera
am Mon, dem 23.07.2007, um 19:24:48 +0200 mailte Paul van den Bogaard
folgendes:
> the manual somewhere states "... if archiving is enabled..." To me
Please don't hijack other threads...
(don't edit a mail-subject to create a new thread. Create a NEW mail!)
Andreas
--
Andreas Kretschmer
Ko
Perhaps you should've read the configuration-manual-page more carefully. ;)
Besides, WAL-archiving is turned off by default, so if you see them
being archived you actually enabled it earlier
The "archive_command" is empty by default: "If this is an empty string
(the default), WAL archiving is
Alvaro,
thanks for the quick reply. Just to make sure: I do not set this
command. This results in the database cycling through a finite set
(hopefully small) set of WAL files. So old WAL files are reused once
the engine thinks this can be done.
Thanks
Paul
On 23-jul-2007, at 19:34, Alva
On Mon, 2007-07-23 at 16:48 +0100, Simon Riggs wrote:
> On Mon, 2007-07-23 at 10:54 -0400, Tom Lane wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > I looked at this last May and my notes say "ExecutorState". I guess that
> > > was wrong, but my analysis showed there was a single malloc o
On Mon, 2007-07-23 at 12:35 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Well, I discover there is an allocation of 8232 (inflation...) made once
> > per statement by a memory context called... ExecutorState. Still not
> > sure exactly which allocation this is, but its def
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> currPos and markPos are defined as BTScanPosData, which is an array of
> BTScanPosItems. That makes BTScanOpaqueData up to 8232 bytes, which
> seems wasteful since markPos is only ever used during merge joins. Most
> of that space isn't even used during m
On Mon, 2007-07-23 at 14:19 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > currPos and markPos are defined as BTScanPosData, which is an array of
> > BTScanPosItems. That makes BTScanOpaqueData up to 8232 bytes, which
> > seems wasteful since markPos is only ever used during
http://blogs.sun.com/jkshah/entry/specjappserver2004_with_glassfish_v2_and
This time with 33% less App Server hardware but same setup for
PostgreSQL 8.2.4 with 4.5% better score .. There has been reduction in
CPU utilization by postgresql with the new app server which means there
is potential
20 matches
Mail list logo
