It would be interesting to get raw performance benchmarks in addition to
PG specific benchmarks. I’ve been measuring raw I/O performance of a few
of our systems and run the following tests as well:
1. 10 runs of bonnie++
2. 5 runs of hdparm -Tt
3. Using a temp file created on the SSD, dd if=tempfi
All,
I currently have access to a matched pair of 20-core, 128GB RAM servers
with SSD-PCI storage, for about 2 weeks before they go into production.
Are there any performance tests people would like to see me run on
these? Otherwise, I'll just do some pgbench and DVDStore.
--
Josh Berkus
Postg
On Tue, Mar 31, 2015 at 8:58 AM, Kevin Viraud <
kevin.vir...@rocket-internet.de> wrote:
> Touche ! Thanks a lot.
>
> Looking more at the data yes it goes very often to ELSE Clause. And
> therefore reaching the MAX_CACHED_RES.
>
> In there anyway to increase that value ?
>
> Basically, I have se
Touche ! Thanks a lot.
Looking more at the data yes it goes very often to ELSE Clause. And
therefore reaching the MAX_CACHED_RES.
In there anyway to increase that value ?
Basically, I have several tables containing millions of rows and let say 5
columns. Those five columns, depending of thei
"Kevin Viraud" writes:
> I have an issue with a rather large CASE WHEN and I cannot figure out why
> it is so slow...
Do all the arms of the CASE usually fail, leaving you at the ELSE?
I suspect what's happening is that you're running into the MAX_CACHED_RES
limit in src/backend/utils/adt/regexp
2015-03-31 11:19 GMT+02:00 Kevin Viraud :
> Hi Pavel,
>
>
>
> Thanks for your answer.
>
>
>
> Yes sure, I could do that, but like I wrote the purpose is not to find a
> way to rewrite it. But to understand why at a certain point it is totally
> going off. I’m aware that the longer my case when wi
Hi Pavel,
Thanks for your answer.
Yes sure, I could do that, but like I wrote the purpose is not to find a way to
rewrite it. But to understand why at a certain point it is totally going off.
I’m aware that the longer my case when will be the longest the query will run.
But 10x slower f
Hi
long CASE can be problem. Why you don't use a dictionary table and join?
Regards
Pavel
2015-03-31 10:53 GMT+02:00 Kevin Viraud :
> Hi,
>
>
>
> I have an issue with a rather large CASE WHEN and I cannot figure out why
> it is so slow...
>
>
>
> First, here is my test query :
>
>
>
> SELECT
Hi,
I have an issue with a rather large CASE WHEN and I cannot figure out why
it is so slow...
First, here is my test query :
SELECT CASE WHEN dwh_company_id = 1
THEN CASE
WHEN wv.source ~ '^$' THEN 'Not tracked'
WHEN wv.source ~ '^1$' THEN 'Not tracked1'
WHEN wv.sour
