Hi, Heikki
> 1. We probably don't want the SQL syntax to be added to the grammar.
> This should be written as an extension, using custom functions as the
> API, instead of extra SQL syntax.
>
> 2. It's not very useful if it's just a dummy replacement for "WHERE
> random() < ?". It has to be mo
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> A variant idea would be to replace the exact cost comparison with a
>> second round of fuzzy cost comparison, but with a much tighter fuzz
>> factor, maybe 1e-6 instead of 0.01.
> Not impressed with this idea- the notion that our m
If I understood correctly the following query should give your answer:
Select opcintype from pg_opclass where opcname = '';
---Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Guillaume Lelarge
Sent: Friday, April 20, 2012 12:5
On Sat, Apr 21, 2012 at 12:20 AM, Simon Riggs wrote:
> On Thu, Apr 19, 2012 at 7:50 PM, Robert Haas wrote:
>> On 4/19/12, Jeff Janes wrote:
>>> The work around would be for the master to refuse to automatically
>>> restart after a crash, insisting on a fail-over instead (or a manual
>>> forcing
Simon Riggs writes:
> On Thu, Apr 19, 2012 at 11:39 PM, Tom Lane wrote:
>> A variant idea would be to replace the exact cost comparison with a
>> second round of fuzzy cost comparison, but with a much tighter fuzz
>> factor, maybe 1e-6 instead of 0.01.
> The fuzz factor is a better idea, IMHO. I
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> A variant idea would be to replace the exact cost comparison with a
>> second round of fuzzy cost comparison, but with a much tighter fuzz
>> factor, maybe 1e-6 instead of 0.01.
> Not impressed with this idea- the notion that our m
"Albe Laurenz" writes:
> Tom Lane wrote:
>> Um, that is what the proposed patch does.
> I was referring to the first two lines that the patch removes.
> I guess I don't understand why they should go.
What we'd have left after the proposed removal is
if (new_path->row
"Albe Laurenz" writes:
> While playing around with ANALYZE on foreign tables, I noticed
> that the row count estimate for foreign scans is still
> initialized to 1000 even if there are statistics for the
> foreign table. I think that this should be improved.
> The attached patch illustrates my s
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> This change would mean that, when two paths have the same pathkeys,
> parameterization, and rowcount, and fuzzily the same cost, that we
> arbitrarily keep the first-submitted one rather than looking at low
> order digits of the costs.
+1 on this approach
Tom Lane wrote:
>> What if you remove the exact cost comparison, but leave the part
where
>> old dominates new based on rows?
>
> Um, that is what the proposed patch does.
I was referring to the first two lines that the patch removes.
I guess I don't understand why they should go.
Anyway, I fail
On Thu, Apr 19, 2012 at 7:50 PM, Robert Haas wrote:
> On 4/19/12, Jeff Janes wrote:
>> The work around would be for the master to refuse to automatically
>> restart after a crash, insisting on a fail-over instead (or a manual
>> forcing of recovery)?
>
> I suppose that would work, but I think Sim
"Albe Laurenz" writes:
> What if you remove the exact cost comparison, but leave the part where
> old dominates new based on rows?
Um, that is what the proposed patch does.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
While playing around with ANALYZE on foreign tables, I noticed
that the row count estimate for foreign scans is still
initialized to 1000 even if there are statistics for the
foreign table. I think that this should be improved.
The attached patch illustrates my suggestion.
BTW, ist there any oth
On 19 April 2012 23:39, Tom Lane wrote:
> The idea that I'm toying with is to try to make the choice a bit less
> platform-specific, by removing the exact cost test that add_path uses
> as its last-ditch comparison step, essentially this:
>
> /*
>
Tom Lane WROTE.
> So after committing the latest round of parameterized-plan hacking,
> I was dismayed to see the buildfarm breaking out in pink, thanks to
> some of the members producing a different plan than expected for one
> test query. I eventually managed to reproduce that (on the fourth
> m
On Thu, Apr 19, 2012 at 11:39 PM, Tom Lane wrote:
> A variant idea would be to replace the exact cost comparison with a
> second round of fuzzy cost comparison, but with a much tighter fuzz
> factor, maybe 1e-6 instead of 0.01.
The fuzz factor is a better idea, IMHO. I would like to see that as
Hi,
I'm working on adding support of range types in pgAdmin and I have a
really hard time understanding the subtype parameter of a range type.
How can I find all the types associated with a specific operator class?
I'm pretty sure it's a really dumb question, but I'm completely lost
here.
Thanks.
17 matches
Mail list logo
