Moritz Onken írta:
>
> Am 19.08.2008 um 17:23 schrieb Moritz Onken:
>
>>
>> Am 19.08.2008 um 16:49 schrieb Scott Carey:
>>
>>> What is your work_mem set to? The default?
>>>
>>> Try increasing it significantly if you have the RAM and seeing if
>>> that affects the explain plan. You may even want
[EMAIL PROTECTED] írta:
>> Hi,
>>
>> I got a question about scalability in high volume insert situation
>> where the table has a primary key and several non-unique indexes
>> on other columns of the table. How does PostgreSQL behave
>> in terms of scalability? The high volume of inserts comes from
Hi,
I got a question about scalability in high volume insert situation
where the table has a primary key and several non-unique indexes
on other columns of the table. How does PostgreSQL behave
in terms of scalability? The high volume of inserts comes from
multiple transactions.
Best regards,
Zol
Hannes Dorbath írta:
Joshua D. Drake wrote:
postgres=# SELECT current_date|| ' a ' || to_char(current_date, 'Day'),
current_date + '1 Year'::interval || ' a ' || to_char(current_date +
'1 Year'::interval, 'Day') as next_birthday;
?column?| next_birthday
--
[EMAIL PROTECTED] írta:
On Fri, Jun 08, 2007 at 08:54:39PM +0200, Zoltan Boszormenyi wrote:
Joshua D. Drake írta:
Zoltan Boszormenyi wrote:
Dave Cramer írta:
It's an IBM x3850 using linux redhat 4.0
Isn't that a bit old? I have a RedHat 4.2 some
Joshua D. Drake írta:
Zoltan Boszormenyi wrote:
Dave Cramer írta:
It's an IBM x3850 using linux redhat 4.0
Isn't that a bit old? I have a RedHat 4.2 somewhere
that was bundled with Applixware 3. :-)
He means redhat ES/AS 4 I assume.
J
I guessed that, hence the smiley.
But
Dave Cramer írta:
It's an IBM x3850 using linux redhat 4.0
Isn't that a bit old? I have a RedHat 4.2 somewhere
that was bundled with Applixware 3. :-)
--
--
Zoltán Böszörményi
Cybertec Geschwinde & Schönig GmbH
http://www.postgresql.at/
---
Greg Smith írta:
On Mon, 21 May 2007, Guido Neitzer wrote:
Yes, that right, but if a lot of the transactions are selects, there
is no entry in the x_log for them and most of the stuff can come from
the cache - read from memory which is blazing fast compared to any
disk ... And this was a pg_b
Jim C. Nasby írta:
On Sun, May 20, 2007 at 08:00:25PM +0200, Zoltan Boszormenyi wrote:
I also went into benchmarking mode last night for my own
amusement when I read on the linux-kernel ML that
NCQ support for nForce5 chips was released.
I tried current PostgreSQL 8.3devel CVS.
pgbench over
PFC írta:
I felt the world needed a new benchmark ;)
So : Forum style benchmark with simulation of many users posting
and viewing forums and topics on a PHP website.
http://home.peufeu.com/ftsbench/forum1.png
One of those curves is "a very popular open-source database which
Jim C. Nasby írta:
On Thu, Jun 15, 2006 at 06:31:02AM +0200, Zoltan Boszormenyi wrote:
Jim C. Nasby ?rta:
On Wed, Jun 14, 2006 at 01:30:10PM +0200, B?sz?rm?nyi Zolt?n wrote:
Replacing random() with a true constant gives me index scan
even if it's hidden inside other fun
Jim C. Nasby írta:
On Wed, Jun 14, 2006 at 01:30:10PM +0200, B?sz?rm?nyi Zolt?n wrote:
Replacing random() with a true constant gives me index scan
even if it's hidden inside other function calls. E.g.:
The database has no choice but to compute random() for every row; it's
marked VOLATI
Hi,
I just noticed that psql's unformatted output uses too much
memory. Is it normal? It seems that psql draws all records
of a query off the server before it displays or writes the output.
I would expect this only with formatted output.
Problem is, I have an export that produces 500'000+ record
Hi,
answering to myself. :-)
Zoltan Boszormenyi írta:
Hi,
I just noticed that psql's unformatted output uses too much
memory. Is it normal? It seems that psql draws all records
of a query off the server before it displays or writes the output.
I would expect this only with formatted o
PFC írta:
create view v1 (code,num) as
select 'AAA',id from table1
union
select 'BBB',id from table2;
As your rows are, by definition, distinct between each subquery,
you should use UNION ALL instead of UNION to save postgres the
trouble of hunting non-existing duplicates. This will
Hi,
we have a VIEW that is an UNION of 12 SELECTs, and every
member of the UNION have a constant field to be able to distinguish
between them.
An often performed operation on this VIEW is to search for only one record
that can be found by the value of the constant field and the serial of
a table
16 matches
Mail list logo
