Re: [pgbr-geral] Informação sobre conversão de tipo automática.
On 12/17/2014 06:08 PM, Matheus de Oliveira wrote: 2014-12-17 14:35 GMT-02:00 Jean Pereira ad...@olostech.com mailto:ad...@olostech.com: CREATE TEMP table table_a (field_a time); Efetuo a inserção de um dado, sendo que utilizo o current_timestamp, e o banco efetua a conversão automática para time na hora que insere. insert into table_a values (current_timestamp); Mas se eu efetuo um simples select utilizando tambem o current_timestamp select * from table_a where field_a = current_timestamp; Bem, existe uma diferença básica. Só para exemplificar o conceito, no PostgreSQL as conversões de tipos são tratadas por funções, sendo que existe três tipos de conversões: - explícitas: são aquelas que você deixa claro, exemplo: CAST(current_timestamp AS time) ou current_timestamp::time - implícitas: (em inglês chamados de implicit casts) são aqueles literalmente implícitos, por exemplo a conversão de int para bigint, um int sempre cabe num bigint, logo essa conversão pode ser feita sem perda alguma, *SEMPRE* - implícitas no assinalamento: (em inglês assignment casts) são usadas em operações de atribuição, por exemplo, num INSERT, num UPDATE ou ALTER TABLE ... ALTER ... TYPE (na verdade só conheço esses três, não sei se tem mais). Sabendo disso fica fácil identificar o seu caso. No INSERT o PostgreSQL irá procurar por um implict cast ou assignment cast de timestamptz para time, existindo (e existe) este será usado. Já no SELECT o PostgreSQL irá procurar primeiro por um operador de igualdade entre os dois tipos em questão, se este não existir (e não existe) aí sim ele irá procurar por um implicit cast, que no caso também não existe, logo o erro (não tenho certeza se a ordem é essa operador depois cast, mas creio que seja). Só pra deixar documentado, se for no psql e executar `\dC 'timestamp with time zone'` irá obter: postgres=# \dC 'timestamp with time zone' List of casts Source type | Target type | Function | Implicit? -+-+-+--- abstime | timestamp with time zone| timestamptz | yes date| timestamp with time zone| timestamptz | yes timestamp without time zone | timestamp with time zone| timestamptz | yes timestamp with time zone| abstime | abstime | in assignment timestamp with time zone| date| date| in assignment timestamp with time zone| timestamp without time zone | timestamp | in assignment timestamp with time zone| timestamp with time zone| timestamptz | yes timestamp with time zone| time without time zone | time| in assignment timestamp with time zone| time with time zone | timetz | in assignment (9 rows) A última linha é o cast que foi usado no seu comando INSERT. Resumindo, os hackers do PostgreSQL acharam que seria razoável a conversão de timestamptz para time de forma implícita, mas somente numa atribuição. Espero que tenha esclarecido. Beleza, obrigado pelas informações. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres http://www.dextra.com.br/postgres/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Monitoramento banco.
2014-12-17 15:52 GMT-02:00 Euler Taveira eu...@timbira.com.br: Você não especificou que tipo de alerta quer (email, sms, jabber, etc). Existem várias ferramentas no mercado que se encaixam no que você especificou (por exemplo, Nagios, Zabbix, Munin e Cacti). Euler, para mim pode ser qualquer tipo de alerta, email seria bom, alguma dessas ferramentas que você citou, é free? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Monitoramento banco.
On 18-12-2014 10:23, Pedro B. Alves wrote: Euler, para mim pode ser qualquer tipo de alerta, email seria bom, alguma dessas ferramentas que você citou, é free? Todas. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Diferença de dados entre '=' e LIKE
Pessoal, apenas comunicando que encontrei a causa do problema. As 2 queries, uma com = e outra com like: select count(*) from ef_usuario u join ef_conta c on c.id_empresa = u.id_empresa join ef_empresa e on e.id_empresa = u.id_empresa where c.status = 'ATIVA' and e.fl_ativo = true; TOTAL = 27285 A mesma query utilizando LIKE, retorna o numero correto de valores. select count(*) from ef_usuario u join ef_conta c on c.id_empresa = u.id_empresa join ef_empresa e on e.id_empresa = u.id_empresa where c.status like 'ATIVA' and e.fl_ativo = true; TOTAL = 29721 Nos 2 casos o que mudava era o uso do indice, o que poderia indicar o índice corrompido, recriei e tudo voltou ao normal lidamente, mas ainda não fazia sentido, pois no server Master esse problema não ocorria. Checando o índice, ele é o único do tipo HASH(e sem sentido algum, apenas por sadismo do DEV), já em desuso no PostgreSQ, então a documentação dá o tapa na cara do DBA. Caution Hash index operations are not presently WAL-logged, so hash indexes might need to be rebuilt with REINDEX after a database crash if there were unwritten changes. Also, changes to hash indexes are not replicated over streaming or file-based replication after the initial base backup, so they give wrong answers to queries that subsequently use them. For these reasons, hash index use is presently discouraged. Muito obrigado Euler, seu lembrete pelo indice corrompido me ajudou mto. Em 17 de dezembro de 2014 15:43, Euler Taveira eu...@timbira.com.br escreveu: On 17-12-2014 10:00, Cleiton Luiz Domazak wrote: O mais bizarro é que se eu importar um dump isso não ocorre. Somente quando restauro com o basebackup ou com PITR, deixando o sincronismo desativado, apenas para replicar a base mesmo. O tipo de campo é VARCHAR. A codificação dos 2 servers está em en_US.UTF-8 A replicação é nativa e assíncrona. Você disse mas não mostrou o problema (como eu fiz no email anterior -- tabelas, consultas, codificações, etc). Portanto, isso pode ser várias coisas incluindo um índice corrompido ou mesmo um bug. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Window functions
Pessoal, é possível utilizar window function para melhorar a select abaixo:? SELECT (SELECT COUNT(*) FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1)) AS totorv , (SELECT COUNT(*) FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1) AND (orv_codsituacao = 5)) AS total , (SELECT string_agg(orv_codorcamento::text,',') FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1) AND (orv_codsituacao = 5)) AS codigos , (ROUNDSELECT COUNT(*) FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1) AND (orv_codsituacao = 5)) * 100)::numeric / (SELECT COUNT(*) FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1))::numeric),2)) AS percentual []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Window functions
On Thu, Dec 18, 2014 at 2:27 PM, Danilo Silva danilo.dsg.go...@gmail.com wrote: Pessoal, é possível utilizar window function para melhorar a select abaixo:? SELECT (SELECT COUNT(*) FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1)) AS totorv , (SELECT COUNT(*) FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1) AND (orv_codsituacao = 5)) AS total , (SELECT string_agg(orv_codorcamento::text,',') FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1) AND (orv_codsituacao = 5)) AS codigos , (ROUNDSELECT COUNT(*) FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1) AND (orv_codsituacao = 5)) * 100)::numeric / (SELECT COUNT(*) FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1))::numeric),2)) AS percentual Não me parece o caso para WINDOW FUNCTION, parece-me o caso para um CASE dentro das funções de agregação: SELECT count(CASE WHEN (orv_codemp = 1) AND (orv_codfilial = 1) END) AS totorv, count(CASE WHEN (orv_codemp = 1) AND (orv_codfilial = 1) AND (orv_codfilial = 1) END) AS total, ... -- adapte os demais FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1) AND ... /* outros filtros que casam com todos */ Já celebrando o lançamento de hoje, algumas horas atrás, da versão 9.4, o mesmo ficaria assim na nova versão somente: SELECT count(*) FILTER(WHERE (orv_codemp = 1) AND (orv_codfilial = 1)) AS totorv, ... Em termos de performance, usar o CASE ou a cláusula FILTER não tem diferença, mas a sintaxe é bem mais organizada... ;-) Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Uso de index
Pessoal,
Estou com um problema,
Tenho uma tabela message que tem indice nos campos created_date, status,
origin, destination
Na queri abaixo o explain utiliza o indice
SELECT id,
status,
content_id,
substring(content from 'maximumDeliveryDate:\(.*?)\,')::DATE AS
maximum_delivery_date,
substring(content from 'customerId:(.*?),') AS customer_id,
substring(content from 'method:(.*?)') AS method,
substring(content from 'createdDate:\(.*?)\,') AS
created_date_message,
substring(content from 'placeId:(.*?),') AS placeId,
created_date
FROM message
WHERE message_type_id IN ('ITEM_PRICE')
AND status IN ('DONE', 'INITIAL')
AND origin = 'ATG'
AND destination = 'BUS'
AND created_date = '2014-11-12 06:00'
ORDER BY maximum_delivery_date ASC;
Sort (cost=860357.09..860357.18 rows=33 width=488)
Sort Key: ((substring(content,
'maximumDeliveryDate:\(.*?)\,'::text))::date)
- Index Scan using
message_message_type_id_created_date_status_origin_destinat_idx on message
(cost=0.00..860356.26 rows=33 width=488)
Index Cond: (((message_type_id)::text = 'ITEM_PRICE'::text) AND
(created_date = '2014-11-12 06:00:00-02'::timestamp with time zone) AND
((status)::text = ANY ('{DONE,INITIAL}'::text[])) AND ((origin)::text =
'ATG'::text) AND ((destination)::text = (...)
Mas quando adicion mais um status na cláusula IN o postgres não utiliza o
indice
SELECT id,
status,
content_id,
substring(content from 'maximumDeliveryDate:\(.*?)\,')::DATE AS
maximum_delivery_date,
substring(content from 'customerId:(.*?),') AS customer_id,
substring(content from 'method:(.*?)') AS method,
substring(content from 'createdDate:\(.*?)\,') AS
created_date_message,
substring(content from 'placeId:(.*?),') AS placeId,
created_date
FROM message
WHERE message_type_id IN ('ITEM_PRICE')
AND status IN ('DONE', 'INITIAL', 'PROCESSED')
AND origin = 'ATG'
AND destination = 'BUS'
AND created_date = '2014-11-12 06:00'
ORDER BY maximum_delivery_date ASC
Sort (cost=901932.88..901932.96 rows=33 width=488)
Sort Key: ((substring(content,
'maximumDeliveryDate:\(.*?)\,'::text))::date)
- Seq Scan on message (cost=0.00..901932.05 rows=33 width=488)
Filter: ((created_date = '2014-11-12 06:00:00-02'::timestamp with
time zone) AND ((message_type_id)::text = 'ITEM_PRICE'::text) AND
((origin)::text = 'ATG'::text) AND ((destination)::text = 'BUS'::text) AND
((status)::text = ANY ('{DONE,INITIAL,PR (...)
Alguém poderia me orientar quanto a este comportamento? Minhas queries
estão demorando muito por causa dele.
Abraços
--
Flávio Alves Granato
gpg: 968F:A938:70B9:82C7:5198:2C74:13CB:2C25:EF1E:726D
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de index
Pessoal,
Estou com um problema,
Tenho uma tabela message que tem indice nos campos created_date, status,
origin, destination
Na queri abaixo o explain utiliza o indice
SELECT id,
status,
content_id,
substring(content from 'maximumDeliveryDate:\(.*?)\,')::DATE
AS maximum_delivery_date,
substring(content from 'customerId:(.*?),') AS customer_id,
substring(content from 'method:(.*?)') AS method,
substring(content from 'createdDate:\(.*?)\,') AS
created_date_message,
substring(content from 'placeId:(.*?),') AS placeId,
created_date
FROM message
WHERE message_type_id IN ('ITEM_PRICE')
AND status IN ('DONE', 'INITIAL')
AND origin = 'ATG'
AND destination = 'BUS'
AND created_date = '2014-11-12 06:00'
ORDER BY maximum_delivery_date ASC;
Sort (cost=860357.09..860357.18 rows=33 width=488)
Sort Key: ((substring(content,
'maximumDeliveryDate:\(.*?)\,'::text))::date)
- Index Scan using
message_message_type_id_created_date_status_origin_destinat_idx on
message (cost=0.00..860356.26 rows=33 width=488)
Index Cond: (((message_type_id)::text = 'ITEM_PRICE'::text) AND
(created_date = '2014-11-12 06:00:00-02'::timestamp with time zone) AND
((status)::text = ANY ('{DONE,INITIAL}'::text[])) AND ((origin)::text =
'ATG'::text) AND ((destination)::text = (...)
Mas quando adicion mais um status na cláusula IN o postgres não utiliza
o indice
SELECT id,
status,
content_id,
substring(content from 'maximumDeliveryDate:\(.*?)\,')::DATE
AS maximum_delivery_date,
substring(content from 'customerId:(.*?),') AS customer_id,
substring(content from 'method:(.*?)') AS method,
substring(content from 'createdDate:\(.*?)\,') AS
created_date_message,
substring(content from 'placeId:(.*?),') AS placeId,
created_date
FROM message
WHERE message_type_id IN ('ITEM_PRICE')
AND status IN ('DONE', 'INITIAL', 'PROCESSED')
AND origin = 'ATG'
AND destination = 'BUS'
AND created_date = '2014-11-12 06:00'
ORDER BY maximum_delivery_date ASC
Sort (cost=901932.88..901932.96 rows=33 width=488)
Sort Key: ((substring(content,
'maximumDeliveryDate:\(.*?)\,'::text))::date)
- Seq Scan on message (cost=0.00..901932.05 rows=33 width=488)
Filter: ((created_date = '2014-11-12 06:00:00-02'::timestamp
with time zone) AND ((message_type_id)::text = 'ITEM_PRICE'::text) AND
((origin)::text = 'ATG'::text) AND ((destination)::text = 'BUS'::text)
AND ((status)::text = ANY ('{DONE,INITIAL,PR (...)
Alguém poderia me orientar quanto a este comportamento? Minhas queries
estão demorando muito por causa dele.
Depende basicamente de dois fatores:
1) Versão do PostgreSQL (porque esse comportamento foi alterado no
planejador).
2) Seletividade da coluna status (por exemplo, se os valores possíveis
dentro dos parênteses cobrem grande parte da tabela, o índice não será
usado).
Se puder nos responder às duas questões acima, talvez possamos ajudar.
Sugiro também tentar mudar por comparações mais simples:
Tente mudar de:
AND status IN ('DONE', 'INITIAL', 'PROCESSED')
Para
AND (status = 'DONE' OR status = 'INITIAL' OR status = 'PROCESSED')
E mande-nos o explain de novo.
[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de index
2014-12-18 15:24 GMT-02:00 Flávio Alves Granato flavio.gran...@gmail.com:
Pessoal,
Estou com um problema,
Tenho uma tabela message que tem indice nos campos created_date, status,
origin, destination
Na queri abaixo o explain utiliza o indice
SELECT id,
status,
content_id,
substring(content from 'maximumDeliveryDate:\(.*?)\,')::DATE AS
maximum_delivery_date,
substring(content from 'customerId:(.*?),') AS customer_id,
substring(content from 'method:(.*?)') AS method,
substring(content from 'createdDate:\(.*?)\,') AS
created_date_message,
substring(content from 'placeId:(.*?),') AS placeId,
created_date
FROM message
WHERE message_type_id IN ('ITEM_PRICE')
AND status IN ('DONE', 'INITIAL')
AND origin = 'ATG'
AND destination = 'BUS'
AND created_date = '2014-11-12 06:00'
ORDER BY maximum_delivery_date ASC;
Sort (cost=860357.09..860357.18 rows=33 width=488)
Sort Key: ((substring(content,
'maximumDeliveryDate:\(.*?)\,'::text))::date)
- Index Scan using
message_message_type_id_created_date_status_origin_destinat_idx on message
(cost=0.00..860356.26 rows=33 width=488)
Index Cond: (((message_type_id)::text = 'ITEM_PRICE'::text) AND
(created_date = '2014-11-12 06:00:00-02'::timestamp with time zone) AND
((status)::text = ANY ('{DONE,INITIAL}'::text[])) AND ((origin)::text =
'ATG'::text) AND ((destination)::text = (...)
Mas quando adicion mais um status na cláusula IN o postgres não utiliza o
indice
(...)
AND status IN ('DONE', 'INITIAL', 'PROCESSED')
AND origin = 'ATG'
AND destination = 'BUS'
AND created_date = '2014-11-12 06:00'
ORDER BY maximum_delivery_date ASC
Sort (cost=901932.88..901932.96 rows=33 width=488)
Sort Key: ((substring(content,
'maximumDeliveryDate:\(.*?)\,'::text))::date)
- Seq Scan on message (cost=0.00..901932.05 rows=33 width=488)
Filter: ((created_date = '2014-11-12 06:00:00-02'::timestamp
with time zone) AND ((message_type_id)::text = 'ITEM_PRICE'::text) AND
((origin)::text = 'ATG'::text) AND ((destination)::text = 'BUS'::text) AND
((status)::text = ANY ('{DONE,INITIAL,PR (...)
Alguém poderia me orientar quanto a este comportamento? Minhas queries
estão demorando muito por causa dele.
Antes de mais nada, nos informe a versão completa do PostgreSQL que está
sendo utilizado e execute um analyze em sua base para atualizar as
estatísticas.
Quantos destes status você tem possíveis? Uma das possíveis causas seria
que o número de ocorrências que contém um dos três status seja tão grande
que o otimizador prefere fazer um seq scan do que utilizar o índice, porém
faça o analyze primeiro, para termos um plano atualizado e adequado para
analisar.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de index
2014-12-18 15:30 GMT-02:00 Flavio Henrique Araque Gurgel fha...@gmail.com: 1) Versão do PostgreSQL (porque esse comportamento foi alterado no planejador). 9.2.7 2) Seletividade da coluna status (por exemplo, se os valores possíveis dentro dos parênteses cobrem grande parte da tabela, o índice não será usado). cobre sim o processed algo como 80% a 90% da tabela com os status = PROCESSED ou DONE o novo explain com a mudança do OR nos status, funcinou que foi uma beleza! Sort (cost=2598.86..2598.86 rows=1 width=488) Sort Key: ((substring(content, 'maximumDeliveryDate:\(.*?)\,'::text))::date) - Index Scan using message_message_type_id_created_date_status_origin_destinat_idx on message (cost=0.00..2598.85 rows=1 width=488) Index Cond: (((message_type_id)::text = 'SALES_ORDER'::text) AND (created_date = '2014-11-12 06:00:00-02'::timestamp with time zone) AND ((origin)::text = 'ATG'::text) AND ((destination)::text = 'BUS'::text)) Filter: (((status)::text = 'ERROR'::text) OR ((status)::text = 'PENDING'::text) OR ((status)::text = 'PROCESSED'::text)) Muito obrigado pela ajuda -- Flávio Alves Granato gpg: 968F:A938:70B9:82C7:5198:2C74:13CB:2C25:EF1E:726D ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de index
2014-12-18 15:31 GMT-02:00 Rafael Fialho rafafial...@gmail.com: Antes de mais nada, nos informe a versão completa do PostgreSQL que está sendo utilizado e execute um analyze em sua base para atualizar as estatísticas. Realizamos sim o analyze. A versão do postgresql é a 9.2.7 Quantos destes status você tem possíveis? Uma das possíveis causas seria que o número de ocorrências que contém um dos três status seja tão grande que o otimizador prefere fazer um seq scan do que utilizar o índice, porém faça o analyze primeiro, para termos um plano atualizado e adequado para analisar. temos 8 status, nós utilizamos o postgresql como um broker de mensagens e tempos várias handles destas mensagens passando por vários estados, talvez seja uma máquina de estado... sei lá. Você esta certíssimo, quando adicionávamos mais opções na cláusula IN o otimizador preferia utilizar o seq scan, com a alteração sugeria pelo Flávio o otimizador voltou a utilizar o Index cond. Muito obrigado pela ajuda. -- Flávio Alves Granato gpg: 968F:A938:70B9:82C7:5198:2C74:13CB:2C25:EF1E:726D ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Window functions
Em 18 de dezembro de 2014 15:12, Matheus de Oliveira matioli.math...@gmail.com escreveu: SELECT count(CASE WHEN (orv_codemp = 1) AND (orv_codfilial = 1) END) AS totorv, count(CASE WHEN (orv_codemp = 1) AND (orv_codfilial = 1) AND (orv_codfilial = 1) END) AS total, ... -- adapte os demais FROM orcamento_venda WHERE (orv_codemp = 1) AND (orv_codfilial = 1) AND ... /* outros filtros que casam com todos */ Valeu Matheus pela dica, apenas troquei o count pelo sum. []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] PostgreSQL 9.4 released
http://www.postgresql.org/about/news/1557/ -- Everton ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
