On Thu, Jun 15, 2006 at 15:38:32 -0400,
John Vincent <[EMAIL PROTECTED]> wrote:
> Any suggestions? FYI the original question wasn't meant as a poke at
> >comparing PG to MySQL to DB2. I'm not making an yvalue judgements either
> >way. I'm just trying to understand how we can use it the best way p
Ok, it works.
Thanks
Franklin
-Mensagem original-
De: Larry Rosenman [mailto:[EMAIL PROTECTED]
Enviada em: sexta-feira, 23 de junho de 2006 19:08
Para: 'Franklin Haut'; pgsql-performance@postgresql.org
Assunto: RE: [PERFORM] Temporary table
Franklin Haut wrote:
> Hello,
>
> I´m have
Franklin Haut wrote:
> Hello,
>
> I´m have some problems with a temporary table, i need create a table,
> insert some values, make a select and at end of transaction the table
> must droped, but after i created a table there not more exist, is
> this normal ?
>
> How to reproduce :
>
>
>
"Franklin Haut" <[EMAIL PROTECTED]> writes:
> How to reproduce :
> CREATE TEMP TABLE cademp (
> codemp INTEGER,
> codfil INTEGER,
> nomemp varchar(50)
> ) ON COMMIT DROP;
> INSERT INTO cademp (codemp, codfil, nomemp) values (1,1,'TESTE');
>
Hello,
I´m have some problems with a temporary table, i need create a table, insert
some values, make a select and at end of transaction the table must droped,
but after i created a table there not more exist, is this normal ?
How to reproduce :
CREATE TEMP TABLE cademp (
Hi for all,Please, Normaly when some SGBD exec the algoritm Nest-Loop Join, there are diferences about the space(buffer) for outer table and inner table. So, I want know where Postgres define the number for this spaces (buffers)? And can I change it?This is very important to me.
luchot <[EMAIL PROTECTED]> writes:
> I would want if it is possible for each pages of a table to have the
> occupation of blocs in percentage in order to see if the page is good full or
> not.
There is not any magic way of getting that information, but you could
modify contrib/pgstattuple to pro
Jim C. Nasby wrote:
> On Wed, Jun 21, 2006 at 01:21:05PM -0300, jody brownell wrote:
>> Jun 21 13:04:04 vanquish postgres[3311]: [19-1] DEBUG: "target": removed
>> 5645231 row versions in 106508 pages
>> Jun 21 13:04:04 vanquish postgres[3311]: [19-2] DETAIL: CPU 3.37s/1.23u sec
>> elapsed 40.6
Hi, Csaba,
Csaba Nagy wrote:
> Well, your application might be completely well behaved and still your
> DBA (or your favorite DB access tool for that matter) can leave open
> transactions in an interactive session. It never hurts to check if you
> actually have "idle in transaction" sessions. It
Hi, Tim,
Seems I sent my message to fast, cut in middle of a sencence:
Markus Schaber wrote:
>> A pg_dump/pg_restore cycle reduced the total
>> database size from 81G to 36G.
> If you still have the original database around,
... can you check wether VACUUM FULL and REINDEX achieve the same effe
Hi, Tim,
Tim Allen wrote:
> One thing that has been
> apparent is that autovacuum has not been able to keep the database
> sufficiently tamed. A pg_dump/pg_restore cycle reduced the total
> database size from 81G to 36G.
Two first shots:
- Increase your free_space_map settings, until (auto)vacuu
Hello,
I see in the documentation that we can obtain the number of pages for a table
with the view named pg_class.
I would want if it is possible for each pages of a table to have the occupation
of blocs in percentage in order to see if the page is good full or not.
I don’t find anything in
12 matches
Mail list logo
