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
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 external
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 special case in the
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.
Well, if
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 narrow it
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
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
operator class,
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
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,
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 of 8228
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 definitely
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 merge
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 merge
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
19 matches
Mail list logo
