throw date - Search results in mailing lists
Mailing lists >> pgsql-performance >> Thread
2021-07-22 16:16:34 | RE: Big performance slowdown from 11.2 to 13.3 (ldh@laurent-hasson.com)
throw an error because it should * be possible to set work_mem and hash_mem_multiplier independently. */ if (hash_mem < MAX_KILOBYTES) return (int) hash_mem; return MAX_KILOBYTES; So basically, we now have
Mailing lists >> pgsql-performance >> Thread
2020-12-23 18:01:07 | Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc. (Gunther Schadow)
throwing hardware at it to parallelize the workflows. There's always going to be one common bottleneck: that database. In my experience of parallelizing workflow processes, I can hammer my PostgreSQL database
Mailing lists >> pgsql-performance >> Thread
2015-11-17 15:26:57 | Re: Why is now()::date so much faster than current_date (Tom Lane)
date_out() will never be invoked at all --- EXPLAIN just throws away the query output
Mailing lists >> pgsql-performance >> Thread
2014-06-12 19:49:13 | Re: OFFSET/LIMIT - Disparate Performance w/ Go application (Andreas Joseph Krogh)
date", l.Id) > Pages that SELECT multiple rows with OFFSET and LIMIT conditions struggle to top 1.3k req/s You don't show us exactly what you're doing with OFFSET/LIMIT, but I'm going
Mailing lists >> pgsql-performance >> Thread
2013-06-27 19:14:40 | Re: Partitions not Working as Expected (Shaun Thomas)
throw away plan caches. I'd actually be OK with that. Fair enough. I'll stop telling devs to use current_date
Mailing lists >> pgsql-performance >> Thread
2012-08-07 14:42:23 | Re: Sequential scan instead of index scan (Jeff Janes)
date part, so what you are doing is fetching a huge number of rows only to throw
Mailing lists >> pgsql-performance >> Thread
2012-08-03 15:26:08 | Re: [ADMIN] Messed up time zones (Steve Crawford)
throw an error. PostgreSQL chooses to use an interpretation. It would be nice if there were a specification as to how such ambiguous data should be interpreted. Perhaps someone can point
Mailing lists >> pgsql-performance >> Thread
2012-03-01 14:41:21 | Re: efficient data reduction (and deduping) (Peter van Hardenberg)
date_trunc('hour', hr_timestamp) 2) Create a view on that showing the last value 3) If you want to throw
Mailing lists >> pgsql-performance >> Thread
2012-02-23 04:40:25 | Very long deletion time on a 200 GB database (Reuven M. Lerner)
throwing that out as one option.) Right now, the best solution to the space problem is to delete information associated with old records, where "old" is from at least 30 days ago. The old records
Mailing lists >> pgsql-performance >> Thread
2011-09-26 20:46:25 | Re: slow query on tables with new columns added. (Filip Rembiałkowski)
date. Regarding your last comment - on that customer_id values should be 0 - if it's a persistent business rule, I would try to create a CHECK to reflect it. With some luck and fiddling
Mailing lists >> pgsql-performance >> Thread
2011-06-30 05:53:25 | near identical queries have vastly different plans (Samuel Gendler)
throw a default value into the resultset wherever a value is missing from the fact table. I have a time dimension and another dimension. I want the cross join to only cross a subset
Mailing lists >> pgsql-performance >> Thread
2010-10-25 17:29:07 | Re: Postgres insert performance and storage requirement compared to Oracle (Merlin Moncure)
throw a couple of indexes in there and you should see some degradation, but nothing too terrible. merlin libpqtypes.esilo.com ins1.c (insert at a time) #include "libpq-fe.h" #include "libpqtypes.h" #define INS_COUNT
Mailing lists >> pgsql-performance >> Thread
2010-03-09 20:40:43 | Re: 10K vs 15k rpm for analytics (Scott Carey)
date RedHat's xfs version is -- there have been enhancements to xfs in the kernel mainline regularly for a long time. In non-postgres contexts, I've grown to appreciate some other qualities: Unlike ext2/3
Mailing lists >> pgsql-performance >> Thread
2007-04-13 19:48:40 | choose_bitmap_and again (was Re: Strangely Variable Query Performance) (Tom Lane)
dates are later than that, but because ineq_histogram_selectivity doesn't trust histogram data unreservedly we compute a selectivity of about 0.99997 for it. That means that the indexes that cover both receipt
Mailing lists >> pgsql-performance >> Thread
2007-04-02 11:51:08 | postgres 7.4 vs. 8.x redux (Alex Deucher)
date | c9 | character varying(100) | c10 | character varying(50) | c13 | integer | Indexes: "t1_pkey" primary key, btree (num) Check constraints: "t1_c13" CHECK (c13 > 0 AND c13 < 6) --------------------------------------- I had some problems a few weeks