k for.
I can supply it if that would help.
Thanks for any advice.
Frank Millman
On 2020-05-26 9:32 AM, Olivier Gautherot wrote:
Hi Frank,
On Tue, May 26, 2020 at 9:23 AM Frank Millman <mailto:fr...@chagford.com>> wrote:
Hi all
I have a SELECT that runs over 5 times slower on PostgreSQL compared
with Sql Server and sqlite3. I am trying to under
On 2020-05-26 11:10 AM, Charles Clavadetscher wrote:
Hello
On 2020-05-26 10:38, Frank Millman wrote:
On 2020-05-26 9:32 AM, Olivier Gautherot wrote:
Hi Frank,
On Tue, May 26, 2020 at 9:23 AM Frank Millman <mailto:fr...@chagford.com>> wrote:
Hi all
I have a SELECT that ru
On 2020-05-26 12:02 PM, Christian Ramseyer wrote:
Hi
On 26.05.20 09:22, Frank Millman wrote:
I have looked at the EXPLAIN, but I don't really know what to look for.
I can supply it if that would help.
My favorite approach to tuning Postgres queries is:
1. Run EXPLAIN ANALYZE
2.
On 2020-05-26 11:27 AM, Charles Clavadetscher wrote:
On 2020-05-26 11:10, Charles Clavadetscher wrote:
Hello
On 2020-05-26 10:38, Frank Millman wrote:
On 2020-05-26 9:32 AM, Olivier Gautherot wrote:
Hi Frank,
On Tue, May 26, 2020 at 9:23 AM Frank Millman <mailto:fr...@chagford.
On 2020-05-26 12:04 PM, David Rowley wrote:
On Tue, 26 May 2020 at 19:23, Frank Millman wrote:
The table sizes are -
my_table : 167 rows
table_1 : 21 rows
table_2 : 11 rows
table_3 : 3 rows
table_4 : 16 rows
Therefore for each tran_date in my_table there are
On 2020-05-26 1:45 PM, David Rowley wrote:
On Tue, 26 May 2020 at 22:31, Frank Millman wrote:
Thank you David. I tried that and it produced the correct result in
53ms, which is what I am looking for.
It will take me some time to understand it fully, so I have some
homework to do!
The
On 2020-05-26 12:04 PM, David Rowley wrote:
Since "my_table" is small, you'd likely be much better doing a manual
rewrite of the query to join a subquery containing the required
details from "my_table". It looks like you want the row_id from the
latest tran_date for each fld_N column. So som
Hi all
Apologies if this is an FAQ, but I could not find the answer I was
looking for.
I want to run two SELECTs, one immediately after the other.
I want to ensure that no other process updates the database in between
the two.
What is the best way to achieve this?
Thanks
Frank Millman
On 2022-08-07 7:54 AM, Ron wrote:
On 8/7/22 00:30, Frank Millman wrote:
Hi all
Apologies if this is an FAQ, but I could not find the answer I was
looking for.
I want to run two SELECTs, one immediately after the other.
I want to ensure that no other process updates the database in
edger_row_id = 1))
(24 rows)
Maybe SQL Server has a way of optimising this, and there is nothing more
I can do. I can live with that. But I just thought I would ask the question.
Thanks for any advice.
Frank Millman
On 2021-03-19 10:29 AM, Thomas Kellerer wrote:
Frank Millman schrieb am 19.03.2021 um 09:19:
This may be a non-issue, and I don't want to waste your time. But perhaps
someone can have a look to see if there is anything obvious I have missed.
I am writing a cross-platform accounting app
On 2021-03-19 11:04 AM, Thomas Kellerer wrote:
Frank Millman schrieb am 19.03.2021 um 09:52:
I am writing a cross-platform accounting app, and I test using Sql
Server on Windows 10 and PostgreSql on Fedora 31. Performance is
usually very similar, with a slight edge to PostgreSql. Now I have a
On 2021-03-19 10:56 AM, Pavel Stehule wrote:
pá 19. 3. 2021 v 9:53 odesílatel Frank Millman <mailto:fr...@chagford.com>> napsal:
On 2021-03-19 10:29 AM, Thomas Kellerer wrote:
> Frank Millman schrieb am 19.03.2021 um 09:19:
>> This may be a non-issue, and I d
On 2021-03-19 12:00 PM, Pavel Stehule wrote:
In this query the most slow operation is query planning. You try to do
tests on almost empty tables. This has no practical sense. You should
test queries on tables with size similar to production size.
Sorry about that. I hope this one is better
On 2021-03-19 12:58 PM, Frank Millman wrote:
QUERY PLAN
Merge Left Join (cost=1401.00..1401.12 rows=1 width=132) (actual
time=3.595
On 2021-03-19 4:38 PM, Tom Lane wrote:
Frank Millman writes:
However, the bizarre thing is that I have simply restored the index to
what it was in the first place. If you look at the table definition in
my original message you can see that all the columns were included in
the index. But the
On 2021-03-19 5:32 PM, Jehan-Guillaume de Rorthais wrote:
On Fri, 19 Mar 2021 14:28:27 +0200
Frank Millman wrote:
[...]
Execution of my main query has improved from 50ms to 33ms. Sql Server
takes 25ms, but this is much better than it was.
[...]
Here is the new EXPLAIN ANALYSE
On 2021-03-19 7:11 PM, Thomas Kellerer wrote:
Frank Millman schrieb am 19.03.2021 um 10:16:
cl_bal selects WHERE tran_date <= '2018-03-31'.
op_bal selects WHERE tran_date < '2018-03-01'.
The second one could be written as WHERE tran_date <= '2018-02-28&#x
19 matches
Mail list logo
