Hi,
Forex and options are in trades table
Best regards
Henrik
Sent from my Mi padOn vinny , Nov 15, 2016 6:46 PM wrote:Are the forex and options in the hist_account_balance table?
The sequential scan is on that table so if they are,
so I'm guessing they should probably by in the
Here are the indexes I have for those queries
Indexes:
hist_account_balance :: "hist_account_balance_ix1" btree (trade_no)
trades :: "trades_pkey" PRIMARY KEY, btree (trade_no)
"trades_trade_date_index" btree (trade_date)
//H
Quoting vinny :
On 201
Hi,
I have some data to join and I want to get som advice from you.
Any tips ? Any comments are apreciated
//H
select trade_no
from
forecast_trades.hist_account_balance
left join trades using (trade_no)
where trade_date > current_date - 120
and trade_date < current_date - 30
and f
Hi,
I have a select moving around a lot of data and takes times
Any advice tuning this query ?
EXPLAIN (ANALYZE ON, BUFFERS ON)
select
d.books,
d.date publish_date,
extract(dow from d.date) publish_dow,
week_num_fixed,
coalesce(sum(case when i.invno is not null then 1 els
Hi,
I will need to anonymized before sending it.
Do you know if there is any tuning documents related to CTE scans
//H
På onsdag 09. november 2016 kl. 14:05:55, skrev Henrik Ekenberg
:
Hi,
I try to tune one Recursive CTE.
Explain Plan can be found here
https://explain.depesz.com/s/yLVd
Hi,
I try to tune one Recursive CTE.
Explain Plan can be found here
https://explain.depesz.com/s/yLVd
Anyone can give me direction to check?
//H.
s
(6 rows)
Boom. This is actually usefull.
It does take 70 seconds for the biggst network though. The index is also
rather large:
public | routes_cidr_to_range_idx | index | htj | routes | 158 MB |
Table is 119MB data. The gist index was 99 MB.
Best regards, Henrik
Henrik Th
e)
Some observations:
- v6 is faster than v4 which is expected.
- The slowest prefixes by all seem to start bits '11'.
However it is only by a factor of 1.5x which is not really significant
Best regards, Henrik
Henrik Thostrup Jensen
Software Developer, NORDUnet
--
S
[.] inet_gist_decompress
1.09% postgres [.] 0x000c067e
1.03% postgres [.] 0x000c047e
0.77% postgres [.] 0x002f0e57
0.75% postgres [.] gistcheckpage
This seemed to stay reletiv
e_gist on routes (cost=0.41..551.93 rows=22900
width=7) (actual time=4.490..21.712 rows=11 loops=732)
Index Cond: ((route)::inet && (hmm.route)::inet)
Planning time: 0.505 ms
Execution time: 15900.669 ms
(6 rows)
Slight faster, but nothing significant. Something seems wonky.
On Wed, 26 Aug 2015, Henrik Thostrup Jensen wrote:
Can you try 9.5 to see if they help?
I'll try installing it and report back.
I upgraded to 9.5 (easier than expected) and ran vacuum analyze.
The query planner now chooses index scan for outer and inner join. This
seems to cut off ro
return some constants, so it is expected. We
developed better ones for 9.5. PostgreSQL 9.5 also supports index
only scans with GiST which can be even better than plain index scan.
OK, that is interesting.
Can you try 9.5 to see if they help?
I'll try installing it and report back.
The main issue seem to be with the gist bitmap index. Is there a better way to
approach this style of query?
Best regards, Henrik
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
13 aug 2008 kl. 17.13 skrev Decibel!:
On Aug 11, 2008, at 9:01 AM, Jeff wrote:
On Aug 11, 2008, at 5:17 AM, Henrik wrote:
OK, changed the SAS RAID 10 to RAID 5 and now my random writes are
handing 112 MB/ sek. So it is almsot twice as fast as the RAID10
with the same disks. Any ideas why
te in random writes?
I'm really keen on trying Scotts suggestion on using the PERC/6 with
mirror sets only and then make the stripe with Linux SW raid.
Thanks for all the input! Much appreciated.
Cheers,
Henke
11 aug 2008 kl. 17.56 skrev Greg Smith:
On Sun, 10 Aug 2008, Henrik wrote:
11 aug 2008 kl. 12.35 skrev Glyn Astill:
It feels like there is something fishy going on.
Maybe the RAID 10
implementation on the PERC/6e is crap?
It's possible. We had a bunch of perc/5i SAS raid cards in our
servers that performed quite well in Raid 5 but were shite in Raid
10. I
ocess = 112074.58 KB/sec
Min xfer= 1024000.00 KB
CPU utilization: Wall time9.137CPU time0.510CPU
utilization 5.58 %
9 aug 2008 kl. 04.24 skrev [EMAIL PROTECTED]:
On Fri, 8 Aug 2008, Henrik wrote:
But r
9 aug 2008 kl. 00.47 skrev Greg Smith:
On Fri, 8 Aug 2008, Henrik wrote:
It feels like there is something fishy going on. Maybe the RAID 10
implementation on the PERC/6e is crap?
Normally, when a SATA implementation is running significantly faster
than a SAS one, it's because th
8 aug 2008 kl. 18.44 skrev Mark Wong:
On Fri, Aug 8, 2008 at 8:08 AM, Henrik <[EMAIL PROTECTED]> wrote:
But random writes should be faster on a RAID10 as it doesn't need to
calculate parity. That is why people suggest RAID 10 for datases,
correct?
I can understand that RAID5 ca
But random writes should be faster on a RAID10 as it doesn't need to
calculate parity. That is why people suggest RAID 10 for datases,
correct?
I can understand that RAID5 can be faster with sequential writes.
//Henke
8 aug 2008 kl. 16.53 skrev Luke Lonergan:
Your expected write speed on a
Hello list,
I have a server with a direct attached storage containing 4 15k SAS
drives and 6 standard SATA drives.
The server is a quad core xeon with 16GB ram.
Both server and DAS has dual PERC/6E raid controllers with 512 MB BBU
There is 2 raid set configured.
One RAID 10 containing 4 SAS d
Hi list,
I'm helping a customer with their new postgresql server and have some
questions.
The servers is connected to a SAN with dual raid cards which all have
512MB cache with BBU.
The configuration they set up is now.
2 SAS 15K drives in RAID 1 on the internal controller for OS.
6 SAS
I've seen some concerns about buying database performance hardware
from DELL. Are there at least some of the RAID cards that work well
with Linux or should I stay clear of DELL permanently?
Thanks!
//Henke
25 jun 2008 kl. 17.45 skrev Greg Smith:
On Wed, 25 Jun 2008, Henrik wrote:
25 jun 2008 kl. 17.45 skrev Greg Smith:
On Wed, 25 Jun 2008, Henrik wrote:
Would you turn off fsync if you had a controller with BBU? =)
Turning off fsync has some potential to introduce problems even in
that environment, so better not to do that. The issue is that you
might have, say
25 jun 2008 kl. 13.15 skrev Matthew Wakeling:
On Wed, 25 Jun 2008, Henrik wrote:
What are your suggestions. What we are currently looking at is.
Dual Quad Core Intel
8 - 12 GB RAM
More RAM would be helpful. It's not that expensive, compared to the
rest of your system.
True, as lo
25 jun 2008 kl. 12.56 skrev Claus Guttesen:
We have a database with lots of small simultaneous writes and reads
(millions every day) and are looking at buying a good hardware for
this.
What are your suggestions. What we are currently looking at is.
Dual Quad Core Intel
8 - 12 GB RAM
10 di
Hi list,
We have a database with lots of small simultaneous writes and reads
(millions every day) and are looking at buying a good hardware for this.
What are your suggestions. What we are currently looking at is.
Dual Quad Core Intel
8 - 12 GB RAM
10 disks total.
4 x 146 GB SAS disk in R
4 okt 2007 kl. 14:30 skrev Alvaro Herrera:
Henrik wrote:
Ahh I had exactly 8 joins.
Following your suggestion I raised the join_collapse_limit from 8
to 10 and
the planners decision sure changed but now I have some crazy
nested loops.
Maybe I have some statistics wrong?
Yeah. The
3 okt 2007 kl. 16:15 skrev Tom Lane:
Henrik <[EMAIL PROTECTED]> writes:
Here is the query if needed.
explain analyze SELECT file_name FROM tbl_file_structure JOIN
tbl_file ON pk_file_id = fk_file_id JOIN tbl_structure ON
pk_structure_id = fk_structure_id JOIN tbl_archive ON pk_arch
job_group_type
= 'B' OR job_group_type IS NULL) GROUP BY file_name, file_ctime,
structure_path, pk_computer_id, filetype_icon, computer_name,
share_name, share_path;
Thanks,
Henrik
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Index Cond: (id = 1)"
"-> Bitmap Heap Scan on test09 (cost=4.33..14.88 rows=10
width=0)"
" Recheck Cond: (id = 1)"
" -> Bitmap Index Scan on test09_id (cost=0.00..4.33
rows=10 width=0)"
"
6 aug 2007 kl. 17:31 skrev Tom Lane:
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
WHERE file_indexed IS FALSE
AND file_copied
IS TRUE
6 aug 2007 kl. 21:47 skrev Heikki Linnakangas:
Henrik Zagerholm wrote:
I know the query retrieves way more which is really necessary to
show to
the user so I would gladly come up with a way to limit the query
so the
GUI doesn't hang for several minutes if a user does a bad search
6 aug 2007 kl. 16:58 skrev Tom Lane:
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
... FROM tbl_file_structure
JOIN tbl_file ON pk_file_id = fk_file_id
JOIN tbl_structure ON pk_structure_id = fk_structure_id
JOIN tbl_archive ON pk_archive_id = fk_arch
6 aug 2007 kl. 15:07 skrev Gregory Stark:
"Henrik Zagerholm" <[EMAIL PROTECTED]> writes:
Hi list,
I'm having a weird acting query which simply retrieves some files
stored in a db
which are related to a specific archive and also has a size lower
than 1024
bytes.
weird thing is the seq scan on
tbl_file_structure and also the insane calculated cost of 100 000 000
on some tables.
Explain analyze below with both seq scan on and off.
Regards,
Henrik
EXPLAIN ANALYZE SELECT pk_file_id, file_name_in_tar, tar_name,
file_suffix, fk_tar_id, tar_compressed
!
Thanks,
Henrik
explain analyze (SELECT max(pk_file_structure_id) as pk_object_id, max
(fk_archive_id) AS fk_archive_id, file_name AS
object_name,
structure_path AS object_path, computer_name
Hello list,
I have a problem with a simple count query on a pgsql 8.2.3 server.
SELECT COUNT(pk_file_structure_id) FROM tbl_file_structure INNER JOIN
tbl_file ON fk_file_id = pk_file_id WHERE lower(file_name) like lower
('awstats%');
Using Explain analyze I've noticed that it makes a seq scan
38 matches
Mail list logo
