AW: Concurrent CTE

Did you look at this approach using dblink already? https://gist.github.com/mjgleaso/8031067 In your situation, you will have to modify the example but it may give an idea where to start. Klaus > -Ursprüngliche Nachricht- > Von: Artur Formella > Gesendet: Dienstag, 3. April 2018 22:

Disable TRUST authentication by using ClientAuthentication_hook

I'd like to disable the TRUST authentication method for certain servers where modification of pg_hba.conf and restarting a service is fairly easy for a number of users. I looked at this example https://wiki.postgresql.org/images/e/e3/Hooks_in_postgresql.pdf It appears that creating a ClientAut

AW: Disable TRUST authentication by using ClientAuthentication_hook

> I'm not sure this is such a good idea. You may need the trust authentication > method, > for example if you forgot the superuser password. Otherwise, there's good > chance > you might use the ClientAuthentication hook to do what you want. Thanks for your feedback. Klaus

AW: Disable TRUST authentication by using ClientAuthentication_hook

> -Ursprüngliche Nachricht- > Von: Tom Lane > > > If you're an server admin you can disable the extension (editing > > shared_pre_load_libraries GUC), change password and then enable the > > extension again... I am aware of this and all the other points. > Or more to the point: exactly

AW: Do we need yet another IDE (SQL development assistant) for PostgreSQL?

We – and the majority of our customers - are mainly focused on Windows. We use pgadmin iii and our own assistants. pgadmin iv ist still too slow on Windows compared to pgadmin iii. That is one reason why we still use PostgreSQL 9.6. That said, one requirement on a commercial tool for us wou

CTE with JOIN of two tables is much faster than a regular query

Running PostgreSQL 9.5 on Windows. The CTE mentioned below completes the query in 4.5 seconds while the regular query takes 66 seconds. I read from EXPLAIN ANALYSE that the regular query starts with a full table scan over "Doc" while the CTE joins the two tables first and applies the filter co

AW: CTE with JOIN of two tables is much faster than a regular query

> -Ursprüngliche Nachricht- > Von: Andreas Kretschmer > Gesendet: Samstag, 18. August 2018 12:27 > Am 18.08.2018 um 11:36 schrieb kpi6...@gmail.com: > > What can I do to improve the performance of the regular query without > > using a CTE? > > try to rewrite it to a subselect: > > s

AW: AW: CTE with JOIN of two tables is much faster than a regular query

> -Ursprüngliche Nachricht- > Von: Adrian Klaver > Gesendet: Samstag, 18. August 2018 16:24 > > To try to replicate what the CTE is doing I would try: > SELECT * > FROM Doc > JOIN (SELECT uDocRef, F.oID, Doc.szText > FROM F JOIN Doc ON F.uDocRef = Doc.udocid) AS D > ON D.uDocRef = D

AW: CTE with JOIN of two tables is much faster than a regular query

> -Ursprüngliche Nachricht- > Von: Stephen Frost > Gesendet: Samstag, 18. August 2018 16:39 Hello, > > > What can I do to improve the performance of the regular query without > > using a CTE? > > You could possibly build a trigram index on the field you're searching, which > could avoi

AW: CTE with JOIN of two tables is much faster than a regular query

> -Ursprüngliche Nachricht- > Von: Tom Lane > Gesendet: Samstag, 18. August 2018 17:29 > > Well, it's simpler than that: filter quals are always evaluated at the lowest > possible plan level. Thank you. This "always" was not clear to me, but it explains a few similar cases (with not-so

AW: CTE with JOIN of two tables is much faster than a regular query

> -Ursprüngliche Nachricht- > Von: Ravi Krishna > Gesendet: Samstag, 18. August 2018 18:25 > > > What can I do to improve the performance of the regular query without > using a CTE? > > Why do you care ? When I find that I can write a SQL 3 different ways, I will > go for the most effic

AW: CTE with JOIN of two tables is much faster than a regular query

> -Ursprüngliche Nachricht- > Von: Tom Lane > Gesendet: Samstag, 18. August 2018 17:29 > > In any case, given that the ILIKE selects so few rows (and the planner knows > it!), finding a way to index that is clearly the right answer. A trigram index took 9 minutes to build but improved th

AW: AW: CTE with JOIN of two tables is much faster than a regular query

> -Ursprüngliche Nachricht- > Von: Tim Cross > Gesendet: Sonntag, 19. August 2018 04:57 > > > > We're using object mapping / entity frameworks (e.g. XPO, Entity > Framework Core). These frameworks support regular queries out-of-the > box; a CTEs require additional effort and are more diffi

AW: Forks of pgadmin3?

This is probably my 10th attempt to move from pgadminIII to pgadmin4. At least the performance has significantly improved over time and seems now acceptable. The biggest drawback is however that all elements are locked up in one browser window – I cannot find any option to detach a query window

AW: Forks of pgadmin3?

Thanks for the link but we're very reluctant to use Java based programs. The main reason is that we need to do some works on servers whose admins simply do not allow to install Java. The screenshots look very promises, however. Regards Klaus > -Ursprüngliche Nachricht- > Von: Thomas K

AW: Forks of pgadmin3?

Thank you, I was not aware of this option - this certainly helps. Regards Klaus Von: Murtuza Zabuawala Gesendet: Freitag, 22. März 2019 18:48 An: kpi6...@gmail.com Cc: PostgreSQL mailing lists Betreff: Re: Forks of pgadmin3? Opening Query tool or Debugger window in a new separate b

Use left hand column for null values

I'm trying to fill up columns containing NULL with the most recent NOT NULL value from left to right. Example: Select 2, 1, null, null, 3 Should be converted into 2, 1, 1, 1, 3 The following query works but I wonder if there is an easier way for tables with 50 or more columns: with

AW: Use left hand column for null values

> [David G. Johnston] > My $0.02​ > > ​Unless you have some need to generalize I'd say ​just brute-force it and be > done. > > You could maybe play with arrays to get something that looks different but I > don't think it would be much shorter to code or easier to understand. My concern