Re: [HACKERS] distinct estimate of a hard-coded VALUES list

On Wed, Aug 16, 2017 at 12:40 PM, Tom Lane wrote: > Jeff Janes writes: > > This patch still applies, and I think the argument for it is still valid. > > So I'm going to make a commit-fest entry for it. Is there additional > > evidence we should gather?

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

Jeff Janes writes: > This patch still applies, and I think the argument for it is still valid. > So I'm going to make a commit-fest entry for it. Is there additional > evidence we should gather? I think we had consensus to apply this at the start of the next development

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

On Tue, Aug 23, 2016 at 5:28 AM, Tom Lane wrote: > Tomas Vondra writes: > > On 08/22/2016 07:42 PM, Alvaro Herrera wrote: > >> Also, if we patch it this way and somebody has a slow query because of a > >> lot of duplicate values, it's easy to

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

On Mon, Aug 22, 2016 at 10:19 AM, Robert Haas wrote: > On Sat, Aug 20, 2016 at 4:58 PM, Tom Lane wrote: > > Jeff Janes writes: > >> On Thu, Aug 18, 2016 at 2:25 PM, Tom Lane wrote: > >>> It does know it, what

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

Tomas Vondra writes: > On 08/22/2016 07:42 PM, Alvaro Herrera wrote: >> Also, if we patch it this way and somebody has a slow query because of a >> lot of duplicate values, it's easy to solve the problem by >> de-duplicating. But with the current code, people that

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

On 08/22/2016 07:42 PM, Alvaro Herrera wrote: Robert Haas wrote: On Sat, Aug 20, 2016 at 4:58 PM, Tom Lane wrote: Jeff Janes writes: On Thu, Aug 18, 2016 at 2:25 PM, Tom Lane wrote: It does know it, what it doesn't know is

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

Robert Haas writes: > On Sat, Aug 20, 2016 at 4:58 PM, Tom Lane wrote: >> I am not exactly sold on this assumption that applications have >> de-duplicated the contents of a VALUES or IN list. They haven't been >> asked to do that in the past, so why do

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

Robert Haas wrote: > On Sat, Aug 20, 2016 at 4:58 PM, Tom Lane wrote: > > Jeff Janes writes: > >> On Thu, Aug 18, 2016 at 2:25 PM, Tom Lane wrote: > >>> It does know it, what it doesn't know is how many duplicates there are. > > > >>

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

On Sat, Aug 20, 2016 at 4:58 PM, Tom Lane wrote: > Jeff Janes writes: >> On Thu, Aug 18, 2016 at 2:25 PM, Tom Lane wrote: >>> It does know it, what it doesn't know is how many duplicates there are. > >> Does it know whether the count

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

Jeff Janes writes: > On Thu, Aug 18, 2016 at 2:25 PM, Tom Lane wrote: >> It does know it, what it doesn't know is how many duplicates there are. > Does it know whether the count comes from a parsed query-string list/array, > rather than being an

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

On Thu, Aug 18, 2016 at 2:25 PM, Tom Lane wrote: > Jeff Janes writes: > > So even though it knows that 6952 values have been shoved in the bottom, > it > > thinks only 200 are going to come out of the aggregation. This seems > like > > a really lousy

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

Jeff Janes writes: > So even though it knows that 6952 values have been shoved in the bottom, it > thinks only 200 are going to come out of the aggregation. This seems like > a really lousy estimate. In more complex queries than the example one > given it leads to poor

[HACKERS] distinct estimate of a hard-coded VALUES list

I have a query which contains a where clause like: aid =ANY(VALUES (1),(45),(87), <6948 more>, (447)) for example: perl -le 'print "explain (analyze) select sum(abalance) from pgbench_accounts where aid=ANY(VALUES "; print join ",", map "($_)", sort {$a<=>$b} map int(rand(500)),