B> scaling will suffer badly on FP functions.
That is half as many 256-bit float units; for scalar math and for
128-bit vector math each core gets a half of the float unit.
Only for the 256-bit vector math do the schedulars have to compete for
float unit access.
-JimC
--
James Cloos
f their cache to better manage
cache-coherency. I presum recent Xeons do so, too, but perhaps yours
are not recent enough for that?
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription
iling the database code, which is not an option for a production
MG> database.
And how exactly, given that the kernel does not know whether the CPU is
active or waiting on ram, could an application do so?
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
--
Sent via pgsql-per
ust that the SSD is fast
enough that the RAM is now the bottleneck, although parsing
and text<=>binary conversions (especially for integers, reals
and anything stored as an integer) also can be CPU-intensive.
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
--
Sent via pgsql-perfor
and comparing.
It can help to use recent versions of gcc with -march=native. And
recent versions of glibc offer improved string ops on recent hardware.
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make ch
width=105)
(actual time=64.831..64.831 rows=0 loops=1)
|Index Cond: ((npa = '7'::bpchar) AND (nxx = '4'::bpchar))
| Total runtime: 64.927 ms
| (3 rows)
`
BTW, I forgot to mention I'm at 8.1.4 on that box.
-JimC
--
James Cloos <[EMAIL PROTECT
e.)
Should I convert the columns to text? Or create an additional index
that expects ::text args? (If so, how?)
Or is there some other way to ensure the indices get used w/o having
to tag data in the queries?
Thanks,
-JimC
--
James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6
---
