id/1415981309.90631.YahooMailNeo%40web133205.mail.ir2.yahoo.com
https://www.postgresql.org/message-id/CAHyXU0yXYpCXN4%3D81ZDRQu-oGzrcq2qNAXDpyz4oiQPPAGk4ew%40mail.gmail.com
https://www.pythian.com/blog/performance-tuning-hugepages-in-linux/
http://structureddata.org/2012/06/18/linux-6-transparent-huge-pages-and-had
.09 rows=1 width=8)
>
Would you send explain ANALYZE and not just explain ?
Justin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to yo
On Fri, Aug 25, 2017 at 03:36:29PM +, Aniko Belim wrote:
> Hi,
>
> We have an issue with one of our partitioned tables. It has a column with
> timestamp without time zone type, and we had to partition it daily. To do
> that, we created the following constraints like this example:
> CHECK (to
r) and pg_dump |pg_restore the relevant
tables (just be sure to specify the alternate host/port/user/etc as needed for
the restore invocation).
Justin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
in default to be documented in the
release notes but can't see that it's.
77cd477c4ba885cfa1ba67beaa82e06f2e182b85
Justin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
quent IDs). I wouldn't bother re-running the query unless
you find that increasing stats target causes the plan to change.
Justin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On 11/6/17, 9:21 AM, "Justin Pryzby" wrote:
> see if statistics improve:
> SELECT (SELECT sum(x) FROM unnest(most_common_freqs) x) frac_MCV,
> tablename, attname, n_distinct, array_length(most_common_vals,1) n_mcv,
> FROM pg_stats WHERE attname~'customers_
=4)
-> Hash (cost=92010.97..92010.97 rows=2121397
width=72) (never executed)
-> Seq Scan on pg_attribute colcld
(cost=0.00..92010.97 rows=2121397 width=72) (never executed)
But is there a better way (I don't consider adding a row of junk to be a
significant improvement).
Thanks in advance for any suggestion.
Justin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Fri, Nov 10, 2017 at 04:19:41PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > (or, the opposite of the more common problem)
> > As the queued_alters table is typically empty (and autoanalyzed with
> > relpages=0), I see "why":
>
> >
;t drop one of the two conditions, you can make PG treat it as a
single condition for purpose of determining expected selectivity, using a ROW()
comparison like:
ROW(qlfy_grp_id, cog_grp_id) = ROW(dlr_grp.dlr_grp_id,
dlr_grp_dlr_xref_1.dlr_grp_id)
If you're running PG96+ you may also be ab
r reports to avoid this kind of thing and support our PG95
customers, but I tentatively would've expected PG10 MV stats to "know" that
USING(site_id, sect_id) is no more selective than USING(sect_id), same as it
knows that's true for WHERE site... AND sect
Justin
--
Sent vi
Hi Everyone
On Fri, Oct 02, 2009 at 12:58:12PM -0700, Justin Pryzby wrote:
> When we upgraded from linux-2.6.24 to linux-2.6.27, our pg_dump
> duration increased by 20% from 5 hours to 6. My first attempt at
On Sat, Oct 03, 2009 at 11:31:11PM -0600, Scott Marlowe wrote:
> between the
On Thu, Oct 08, 2009 at 10:49:37AM -0700, Joshua D. Drake wrote:
> On Thu, 2009-10-08 at 10:44 -0700, Justin T Pryzby wrote:
> > Hi Everyone
> Did your scheduler change between the kernel versions?
No, it's deadline for both.
Justin
--
Sent via pgsql-performance mailing list (
On Thu, Oct 08, 2009 at 03:37:39PM -0500, Kevin Grittner wrote:
> Justin T Pryzby wrote:
> > On Thu, Oct 08, 2009 at 10:49:37AM -0700, Joshua D. Drake wrote:
> >> Did your scheduler change between the kernel versions?
> > No, it's deadline for both.
>
>
101 - 114 of 114 matches
Mail list logo
