When it is valid to filter based on a HAVING clause predicate, it should
already have been converted into a WHERE clause predicate, except in the
special case of an LIMIT TO .k .. ORDER BY case where the HAVING clause
predicate can be determined approximately after having found k fully
Peter, I'm very glad to hear that you're researching this!
Will this include skip-scan optimizations for OR or IN predicates, or when the
number of distinct values in a leading non-constant index column(s) is
sufficiently small? e.g. suppose there is an ORDER BY b, and WHERE clause
predicates
Or if you know the frequencies of the highly frequent values of the
partitioning key at the time the partition bounds are defined, you could define
hash ranges that contain approximately the same number of rows in each
partition. A parallel sequential scan of all partitions would then perform
This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know the
content is safe.
Alvaro Herrera writes:
> On 2022-Oct-24, Finnerty, Jim wrote:
>> The advantage of hash partition bounds is that they ar
Is there a reason why HASH partitioning does not currently support range
partition bounds, where the values in the partition bounds would refer to the
hashed value?
The advantage of hash partition bounds is that they are not domain-specific,
as they are for ordinary RANGE partitions, but they
Tom, two quick questions before attempting to read the patch:
Given that views are represented in a parsed representation, does anything
need to happen to the Vars inside a view when that view is outer-joined to?
If an outer join is converted to an inner join, must this information
Re: So I'm actually using the columns during merge join, basically I'm building
a bloom filter on the outer relation and filtering out data on the inner
relation of the join. I'm building the filter on the join keys
We had a whole implementation for Bloom filtering for hash inner join, complete
Specifying the library name before the language-country code with a new
separator (":") as you suggested below has some benefits. Did you consider
making the collation version just another collation attribute, such as
colStrength, colCaseLevel, etc.?
For example, an alternate syntax might
Can we get some more consistent terminology around the term "locale"?
In ICU, the "locale" is just the first part of what we can pass to the "locale"
parameter in CREATE COLLATION - the part before the optional '@' delimiter.
The ICU locale does not include the secondary or tertiary
So I think knowing what bad it is to have this feature is the key point to
discussion now.
> While I've only read your description of the patch not the patch itself,
This comment applies to me also.
Is the join selectivity properly calculated in all cases, e.g. in the n:m join
case in
On 10.01.22 12:49, Daniel Verite wrote:
> I think some users would want their db-wide ICU collation to be
> case/accent-insensitive.
...
> IIRC, that was the context for some questions where people were
> enquiring about db-wide ICU collations.
+1. There is the DEFAULT_COLLATION_OID, which
Re:
>> After this patch goes in, the big next thing would be to support
>> nondeterministic collations for LIKE, ILIKE and pattern matching operators in
>> general. Is anyone interested in working on that?
> As far as I know you're the last person that seemed to be working on that
> topic
>
Re: patch that uses XID_FMT everywhere ... to make the main patch much smaller
That's exactly what my previous patch did, plus the patch to support 64-bit
GUCs.
Maxim, maybe it's still a good idea to isolate those two patches and submit
them separately first, to reduce the size of the rest of
Re:The "prepare" approach was the first tried.
https://github.com/postgrespro/pg_pageprep
But it appears to be very difficult and unreliable. After investing
many months into pg_pageprep, "double xmax" approach appears to be
very fast to implement and reliable.
I'd still like
Re: clog page numbers, as returned by TransactionIdToPage
- int pageno = TransactionIdToPage(xid); /* get
page of parent */
+ int64 pageno = TransactionIdToPage(xid); /* get page of
parent */
...
- int pageno =
Re:Most software has a one-stage upgrade model. What you propose would
have us install 2 things, with a step in-between, which makes it
harder to manage.
The intended benefit would be that the code doesn't need to handle the
possibility of 2 different XID representations for the
I didn't notice anything version-specific about the patch. Would any
modifications be needed to backport it to pg13 and pg14?
After this patch goes in, the big next thing would be to support
nondeterministic collations for LIKE, ILIKE and pattern matching operators in
general. Is anyone
(Maxim) Re: -- If after upgrade page has no free space for special data, tuples
are
converted to "double xmax" format: xmin became virtual
FrozenTransactionId, xmax occupies the whole 64bit.
Page converted to new format when vacuum frees enough space.
A better way would be
On 1/4/22, 2:35 PM, "Stephen Frost" wrote:
>>
>>Not saying that I've got any idea how to fix that case offhand, and we
>>don't really support such a thing today as the server would just stop
>>instead, ...
>> Perhaps that's a
>> worthwhile tradeoff for being able to generally
> But making everything slower will be a hard sell, because vast majority of
> workloads already running on Postgres don't have this issue at all, so
> for them it's not worth the expense. Following the insurance analogy,
> selling tornado insurance in Europe is mostly pointless.
>
Agree. I've
I have a proposal for how to support tailoring rules in ICU collations: The
ucol_openRules() function is an alternative to the ucol_open() function that
PostgreSQL calls today, but it takes the collation strength as one if its
parameters so the locale string would need to be parsed before
Re:
>> Can a CI collation be ordered upper case first, or is this a limitation
of ICU?
> I don't know the authoritative answer to that, but to me it doesn't make
> sense, since the effect of a case-insensitive collation is to throw away
> the third-level weights, so there is
>>
You can have these queries return both rows if you use an
accent-ignoring collation, like this example in the documentation:
CREATE COLLATION ignore_accents (provider = icu, locale =
'und-u-ks-level1-kc-true', deterministic = false);
<<
Indeed. Is the dependency between the
We are applying the Babelfish commits to the REL_12_STABLE branch now, and the
plan is to merge them into the REL_13_STABLE and master branch ASAP after that.
There should be a publicly downloadable git repository before very long.
On 2/12/21, 2:35 PM, "Peter Geoghegan" wrote:
CAUTION:
Many will want to use it to do aggregation, e.g. a much more efficient
COUNT(*), because they want performance and don't care very much about
transaction consistency. E.g. they want to compute SUM(sales) by salesperson,
region for the past 5 years, and don't care very much if some concurrent
Re: " It appears that the second row was in place originally, then got updated
by a trigger (and even deleted later on, although it doesn't appear that the
delete transaction got committed), and then the first row was inserted within
the same transaction that updated the second row."
If you
If the function was moved to the FROM clause where it would be executed as a
lateral cross join instead of a target list expression, how would this affect
the cost-based positioning of the Gather?
On 9/23/19, 8:59 AM, "Robert Haas" wrote:
On Sun, Sep 22, 2019 at 7:47 AM Darafei "Komяpa"
Fwiw, I had an intern do some testing on the JOB last year, and he reported
that geqo sometimes produced plans of lower cost than the standard planner (we
were on PG10 at the time). I filed it under "unexplained things that we need
to investigate when we have time", but alas...
In any case,
I feel strongly that eliminating the entire DISTINCT or GROUP BY clause (when
there are no aggs) is an important optimization, especially when the
incremental cost to test for it is so tiny. I'm happy to submit that as a
separate thread.
My goal here was to move the original proposal along
Congratulations, everyone! (I wonder if we have any female PG committers?)
On 6/4/18, 9:14 AM, "Jesper Pedersen" wrote:
On 06/01/2018 05:05 PM, Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
30 matches
Mail list logo
