Vous n'êtes pas identifié(e).
C'est effectivement possible mais avec psql directement:
\i table.sql
\i vue.sql
etc...
Pour pgadmin, je l'ignore par contre
Cordialement
Bonsoir,
tes dates sont bien enregistrées dans des colonnes au format date ?
Sinon, il faudrait peut être les transformer avant avec un to_date('15/10/2017','DD/MM/YYYY')
@+
Bonsoir,
contre toute attente, ça marche aujourd'hui ! j'ignore si c'est la dernière mise à jour.
Par contre, il me semble que lorsque j'ai parlé du problème, tous les fichiers dans le repertoire
/etc/systemd/system/multi-user.target.wants/ étaient en dur. aujourd'hui tout est en lien ! est ce l'effet du daemon-reload ?
Merci à tous de votre aide.
Bonjour, après vérification sur une autre machine, même type d'installation (Fedora 25 -> Fedora 26), postgresql se lance au démarrage sans soucis et le fichier service est rigoureusement le même.
J'ai mis à jour le copier collé du fichier service , j'avais malheuresement raté un bout sur le précédent.
Bien sur:
# It's not recommended to modify this file in-place, because it will be
# overwritten during package upgrades. It is recommended to use systemd
# "dropin" feature; i.e. create file with suffix .conf under
# /etc/systemd/system/UNITNAME.service.d directory overriding the
# unit's defaults. Look at systemd.unit(5) manual page for more info.
[Unit]
Description=PostgreSQL database server
After=network.target
[Service]
Type=forking
User=postgres
Group=postgres
# Where to send early-startup messages from the server (before the logging
# options of postgresql.conf take effect)
# This is normally controlled by the global default set by systemd
# StandardOutput=syslog
# Disable OOM kill on the postmaster
OOMScoreAdjust=-1000
# ... but allow it still to be effective for child processes
# (note that these settings are ignored by Postgres releases before 9.5)
Environment=PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
Environment=PG_OOM_ADJUST_VALUE=0
# Maximum number of seconds pg_ctl will wait for postgres to start. Note that
# PGSTARTTIMEOUT should be less than TimeoutSec value.
Environment=PGSTARTTIMEOUT=270
Environment=PGDATA=/var/lib/pgsql/data
ExecStartPre=/usr/libexec/postgresql-check-db-dir %N
# Use convenient postgresql-ctl wrapper instead of directly pg_ctl. See the
# postgresql-ctl file itself for more info.
ExecStart=/usr/libexec/postgresql-ctl start -D ${PGDATA} -s -w -t ${PGSTARTTIMEOUT}
ExecStop=/usr/libexec/postgresql-ctl stop -D ${PGDATA} -s -m fast
ExecReload=/usr/libexec/postgresql-ctl reload -D ${PGDATA} -s
# Give a reasonable amount of time for the server to start up/shut down.
# Ideally, the timeout for starting PostgreSQL server should be handled more
# nicely by pg_ctl in ExecStart, so keep its timeout smaller than this value.
TimeoutSec=300
[Install]
WantedBy=multi-user.targetmerci de vous intéresser au problème.
J'ai googlé sur le sujet mais sans succès.
edit : correction du copié collé
@+
Bonjour,
voila quelques jours que je me bats avec ma Fedora 26 mise a jour depuis une 25 ou tout fonctionnait bien !
J'ai installé postgresql depui le repo officiel. J'arrive à démarrer le service manuellement en faisant :
$ sudo systemctl start postgresqlavec ce résultat:
$ sudo systemctl status postgresql
● postgresql.service - PostgreSQL database server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
Active: active (running) since Sun 2017-09-17 10:47:12 CEST; 33min ago
Process: 4603 ExecReload=/usr/libexec/postgresql-ctl reload -D ${PGDATA} -s (code=exited, status=0/SUCCESS)
Process: 4158 ExecStart=/usr/libexec/postgresql-ctl start -D ${PGDATA} -s -w -t ${PGSTARTTIMEOUT} (code=exited, status=0/SUCCESS)
Process: 4156 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgresql (code=exited, status=0/SUCCESS)
Main PID: 4160 (postgres)
Tasks: 7 (limit: 4915)
CGroup: /system.slice/postgresql.service
├─4160 /usr/bin/postgres -D /var/lib/pgsql/data
├─4161 postgres: logger process
├─4163 postgres: checkpointer process
├─4164 postgres: writer process
├─4165 postgres: wal writer process
├─4166 postgres: autovacuum launcher process
└─4167 postgres: stats collector process
sept. 17 10:47:11 localhost.localdomain systemd[1]: Starting PostgreSQL database server...
sept. 17 10:47:11 localhost.localdomain postgresql-ctl[4158]: LOG: redirection des traces vers le processus de récupération des traces
sept. 17 10:47:11 localhost.localdomain postgresql-ctl[4158]: ASTUCE : Les prochaines traces apparaîtront dans le répertoire « pg_log ».
sept. 17 10:47:12 localhost.localdomain systemd[1]: Started PostgreSQL database server.
sept. 17 10:52:16 localhost.localdomain systemd[1]: Reloading PostgreSQL database server.
sept. 17 10:52:16 localhost.localdomain systemd[1]: Reloaded PostgreSQL database server.mais impossible de le faire se lancer au démarrage avec la commande habituelle:
$ sudo systemctl enable postgresqlj'obtiens ce message d'erreur:
$ sudo systemctl enable postgresql
Synchronizing state of postgresql.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable postgresql
erreur lors de la lecture d'informations sur le service postgresql : Invalid argumentle répertoire /var/lib/pgsql/data est créé correctement et postgresql fonctionne lors du lancement manuel !
si quelqu'un a une idée, je lui serais reconnaissant car je sèche complètement.
@+
Ce n'est pas lié au SQL, c'est pour spécifier le flag "global" à la recherche regexp, c'est-à-dire ne pas s'arrêter à la première occurence trouvée.
un peu comme dans sed ! 
ravi de la question, je découvre aussi !
@+
Bonsoir et merci de vos réponses, j'ai fait des essais avec FREEZE (je recrée mes tables a chaque fois donc elle sont vides) et effectivement, j'ai gagné près de 30 % de temps de remplissage.
Merci a tous
Bonsoir à tous,
pour mes besoins au boulot, je crée régulièrement une BDD sous postgresql en important une ribambelle de CSV avec la commande copy via des scripts sql lus par psql. Les plus grosse tables doivent faire quelques dizaine de milliers lignes, voire centaines pour 2 ou 3 d'entre elles (mais avec peu de colonnes), mais pas beaucoup plus.
Je trouve pas ça toujours très rapide (j'utilise une station de travail comme serveur).
Y'a il une methode plus rapide/efficace pour injecter mes données en bases ? un ETL ? python+pandas ? Une stratégie a adopter dans les scripts ?
Cordialement
Bonjour, as tu essayé :
select to_char(tel, '99 9999 9999') from table; ?
Bonsoir,
sinon, dbeaver permet ce genre de comportement (filtrer en clic droit sur une valeur) et offre également la complétion, ce qui est bien agréable.
Bonjour, manifestement tu es sous Windows, je te conseille donc de récupérer Notepad++, d'ouvrir ton fichier avec, de convertir en UTF-8 (sans bom) et de le sauver tel quel avant de réimporter.
Cordialement
Autre solution, en se référent à la formule de cette page: http://wiki.postgresql.org/wiki/Aggregate_Median
on convertit les dates en délais (admettons que ma plantation soit en 2014-03-01):
select gr,median(stade-'2014-03-01') from test group by gra rajouter à la date de plantation (mais j'ai du mal avec les opération sur les dates).
Cordialement
Sinon, pour repartir de ton exemple:
/*
create table test ( id int, gr char(1), stade date);
insert into test values (1,'A','2014-05-22');
insert into test values (2,'A','2014-05-19');
insert into test values (3,'A','2014-05-20');
insert into test values (4,'B','2014-05-15');
insert into test values (5,'B','2014-05-13');
insert into test values (6,'B','2014-05-14');
insert into test values (7,'B','2014-05-16');
*/
with foo as(
with tmp as (
select gr, stade, rank() over (partition by gr order by stade asc) from test
)
select gr, round(max(rank+1)/2) as rank
from tmp
group by gr), bar as (select gr, stade, rank() over (partition by gr order by stade asc) from test
)
select bar.gr, bar.stade
from foo inner join bar using (gr, rank)me donne:
"A";"2014-05-20"
"B";"2014-05-14"
mais vu le code alambiqué, je doutes que ce soit très perfomant sur des très grosse séries.
Cordialement
Bonjour, s'agissant de traiter une médiane, j'imagine qu'au delà de la date médiane, il s'agit de calculer le délai median entre la plantation et l'épiaison. Pourquoi dans ce cas ne pas calculer ces délais en amont, quitte à reconvertir en date si besoin. Faire une médiane sur un entier est déjà plus simple. Ne pas oublier également que la médiane se calcule différemment suivant que le nombre de valeurs est pair ou impair.
Mais faire des stats sur des dates, c'est toujours assez prise de tête.
@+
Merci pour le lien, c'est beaucoup plus pointu que ne le laissait supposer ma question puisque même l'ordre des tables à une importance.
Au final, dans mon cas, le gain sera marginal.
Cordialement
Jusqu'ici, on est bien d'accord.
Ce que je me demande, c'est : si pour une valeur dont je sais qu'elle ne dépassera pas 199 par exemple, il est plus intéressant d'utiliser un smallint (2) ou un integer (4) fera aussi bien sans que ce soit la peine de s'enquiquiner ? Est ce que ça joue vraiment sur les performance ?
@+
Bonjour,
select 'coucou c''est moi'devrait le faire.
@+
Bonjour à tous,
y'a t-il un intérêt quelconque (performance) à déclarer des smallint ? ou le integer (int4) classique suffit-il ?
Cordialement
C'est plus une migration, non ?
ora2pg ?
Cordialement
Le fameux BOM (BYTE ORDER MARK). J'ai essayé de reproduire avec une 9.2 sous linux, sans succès.
C'est donc peut être aussi lié à la version de pg. Un peu plus de renseignment ne serait pas inutile. OS, version de PG, etc...
Cordialement
La base de données postgres utilise l'encodage UTF8. Si le fichier à importé n'a pas le même encodage, PG ne l'importe pas. A moins que j'ai mal compris ta suggestion, je ne suis pas sûr que le problème vienne de là.
Pourtant, je travaille a moitié sous win et linux et ça a été une bonne source de nuits blanches.
T'es sous quel OS ?
@+
Bonsoir,
j'ai déjà eu ce genre de chose. Pb d'encodage du fichier par rapport à pg il me semble.
UTF8 avec BOM, ou un truc dans ce genre.
C'est par la que je commencerai à chercher en tous cas.
Cordialement
Bonsoir,
ça marche, j'ai déjà fait quelques essais avec, mais je trouve ça un peu usine a gaz (surtout quand on ne cause ni java, ni javascript) pour mes besoins. J'aurai préféré que ce soit du python !
Cela dit, il y a des choses très puissante dans ce genre d'outils.
Par contre, y'a un truc bizarre, c'est le sens de la flèche sur les composants BDD, il faut faire à l'inverse du feeling !
@+