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?
>
> I think we had consensus to apply this
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 cycle; I just forgot to d
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 solve the problem by
> >> de-duplicating. But with t
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 it doesn't know is how many duplicates there are.
> >
> >> Does it know whether the c
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 have the
>> opposite problem has
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 how many duplicates there are.
Does it know whether the count
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 you think they are doing it?
> It's hard t
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.
> >
> >> Does it know whether the count comes from a parsed query-strin
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 comes from a parsed query-string list/array,
>> rather than be
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 estimate from something else? If it came from a j
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 estimate. In more complex queries than the
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 planning choices.
> Is th
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)), 1..6952
13 matches
Mail list logo
