he WAL
starting address is set to a valid value.
Allowing changes to the WAL segment size during pg_upgrade seems like a
nice way to avoid needing a dump and load, so I would like to propose
adding support for this. I'd be happy to submit patches for this in the
next commitfest.
else
+ appendPQExpBuffer(dbQry, "COMMENT ON DATABASE
%s IS ", fmtId(datname));
This feature would probably only be added to v11, so the version
checks in the pgdump patch will need to be updated.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/1/17, 9:33 PM, "Peter Eisentraut"
wrote:
> On 9/25/17 14:04, Bossart, Nathan wrote:
>> I'd like to use this thread to gauge community interest in adding this
>> functionality to this module. If there is interest, I'll add it to the next
>> commit
On 10/5/17, 12:29 AM, "Michael Paquier" wrote:
> On Thu, Oct 5, 2017 at 1:23 AM, Bossart, Nathan wrote:
>> Presently, there are a few edge cases in vacuum_rel() and analyze_rel() that
>> I
>> believe do not have sufficient logging. This was discussed a bit in t
or any tables not explicitly named.
>
> In any case, though, the extent to which we should add more warning
> or log output seems like a fit topic for a new thread and a separate
> patch. Let's call this one done.
I'll look into submitting that to the next commitfest.
Nathan
les, which Tom has indicated he will handle.
Yes. It looks like v10 is safe, and the vacuum-multiple-relations
patch should help prevent any future logging issues caused by this.
Discussion here:
http://postgr.es/m/CAB7nPqRX1465FP%2Bameysxxt63tCQDDW6KvaTPMfkSxaT1TFGfw%40mail.gmail.com
Nathan
On 9/28/17, 8:46 PM, "Michael Paquier" wrote:
> On Fri, Sep 29, 2017 at 10:44 AM, Tom Lane wrote:
>> Michael Paquier writes:
>>> On Fri, Sep 29, 2017 at 2:44 AM, Bossart, Nathan
>>> wrote:
>>>> Alright, I've added logging for auto
og for partitions.
However, I'm dubious that it is necessary to make such a big change so
close to release for hypothetical log statements. So, in the end, I agree
with you.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
On 9/27/17, 7:41 AM, "Peter Eisentraut"
wrote:
> On 9/25/17 23:10, Bossart, Nathan wrote:
>> One interesting design challenge will be how to handle pre-hashed
>> passwords, since the number of checks we can do on those is pretty
>> limited. I'm currently thin
l.org/message-id/25023.1506107...@sss.pgh.pa.us
> are settled.
Makes sense.
> +VACUUM FULL vactst, vactst, vactst, vactst;
> This is actually a waste of cycles.
I'll clean this up in v22.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/26/17, 2:38 AM, "Albe Laurenz" wrote:
> Nathan Bossart wrote:
>>>> passwordcheck.force_new_password
>>>>
>>> Does it mean a password different from the old one? +1. It could be
>>> different from the last 3 passwords but we don&
On Mon, Sep 25, 2017 at 07:52:19PM +0100, Oliver Ford wrote:
> Thanks for your review. The issue is that Oracle throws errors on many
> more input cases than Postgres does, so making it exactly like Oracle
> could break a lot of existing users. E.g. to_number ('123,000', '999')
> returns '123' on
ds are forced
and min_password_length is nonzero). Thoughts?
Also, I imagine we'll want to keep the cracklib and "password cannot
contain role name" features around, although perhaps these could become
configurable like the rest of the options.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
This is just a minor point, and I could see the argument that your
phrasing is more concise, anyway.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
re is interest, I'll add it to the next
commitfest.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
looked up here.
I think this could be slightly misleading. Perhaps it would be more
accurate to say that the lock will be gone any time vacuum() creates a new
transaction (either in vacuum_rel() or when use_own_xacts is true).
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On Thu, Aug 17, 2017 at 12:33:02PM +0100, Oliver Ford wrote:
> Ok I've made that change in the attached v3. I'm not sure as I'm on
> en_US.UTF-8 locale too. Maybe something Windows specific?
This patch applies against master (8485a25a), compiles, and
passes a make check.
I tested both on my mac
On 9/23/17, 12:36 PM, "Tom Lane" wrote:
>"Bossart, Nathan" writes:
>> This looks reasonable to me as well. I haven't noticed any issues after
>> a couple hours of pgbench with aggressive autovacuum settings, either.
>
> Thanks for looking. As I
have would be to add an assertion
> at the top of perform_work_item to be sure that it is called in the
> memory context of AutovacMemCxt.
This looks reasonable to me as well. I haven't noticed any issues after
a couple hours of pgbench with aggressive autovacuum settin
able fix,
> too. 0002 as it stands is useless as a back-patch basis, since it
> proposes modifying code that doesn't even exist in the back branches.
I'd be happy to write something up that is more feasibly back-patched.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
n true;
+}
There are some inconsistencies in the naming strategy. For
example, this function is called _equalDatabaseSpec(), but the
struct is DBSpecName. I would suggest calling it DatabaseSpec or
DbSpec throughout the patch.
Nathan
[1] https://travis-ci.org/postgresql-cfbot/postgresql/builds/2757
e much value for this
particular use case (i.e. 'VACUUM;'). If a user does not provide a list
of tables to VACUUM, they might not care too much about WARNINGs for
dropped tables.
> Are there opinions about back-patching the patch checking for
> duplicate columns? Stable branches now co
you that perhaps we should not try to infer
the intent of the user in these "duplicate" scenarios.
I'll work on converting the existing de-duplication patch into
something more like what you suggested.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
ommand, one that I, like others much earlier in this thread,
was surprised to learn wasn't supported.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ult that we are at this
> state, I am fine as well to remove this burden from you, Nathan, and
> fix that myself in a new version. And I don't want to step on your
> toes either :)
No worries, I can take care of it. I appreciate your patience with all
of these reviews.
Nathan
keNode(VacuumRelation);
> + vacrel->relation = relation;
> + vacrel->va_cols = va_cols;
> + vacrel->oid = oid;
> + return vacrel;
> +}
> Perhaps in makefuncs.c instead of vacuum.c? That's usually the place
> used for node constructions like that.
Ah, ye
specified columns. For example,
"ANALYZE table (a, b), table;" currently dedupes to the equivalent of
"ANALYZE table (a, b);" when it should dedupe to "ANALYZE table;".
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 5/18/17, 8:03 PM, "Tom Lane" wrote:
>”Bossart, Nathan" writes:
>> On 5/18/17, 6:12 PM, "Michael Paquier" wrote:
>>> Fine for me as well. I would suggest to split the patch into two parts
>>> to ease review then:
>>> - Rewo
ll, and almost
all of the same code needs to be changed in the main patch anyway. I do not
foresee a huge impact on review-ability either way. If others disagree, I can
split it up.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
On 5/16/17, 11:21 PM, "Michael Paquier" wrote:
> On Wed, May 17, 2017 at 7:56 AM, Bossart, Nathan wrote:
>> I think this issue already exists, as this comment in get_rel_oids(…) seems
>> to indicate:
>>
>> /*
>> * Since we don't take
to the specified relid.
> s/rels/relations/ as variable name?
Agreed, that seems nicer.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that we remember to look at it when the time comes.
Understood. I’ve added it to the commitfest.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
already get all per-table information when you do not specify a
table name (“VACUUM VERBOSE;”), so I would expect to get this for free as long
as we are building this into the existing ExecVacuum(…) and vacuum(…) functions.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
Great, I’ll keep working on this patch and will update this thread with a more
complete implementation.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Nov 06, 2015 at 02:16:41PM -0500, Tom Lane wrote:
> Uh, what? It's not by any means turned off by default.
>
> postgres=# select name,setting from pg_settings where name like '%geqo%';
> name | setting
> -+-
> geqo| on
[snip]
On Fri, Nov 06, 2015 at 11:45:38AM -0500, Tom Lane wrote:
> However, really the whole argument is moot, because I notice that
> geqo_mutation() is only called in the "#ifdef CX" code path, which
> we don't use.
I suppose someone could turn it on via a compiler define.
> So there's little point i
On Fri, Nov 06, 2015 at 11:19:00AM -0500, Tom Lane wrote:
> Nathan Wagner writes:
> > I see you committed a modified version of my patch in commit
> > 59464bd6f928ad0da30502cbe9b54baec9ca2c69.
>
> > You changed the tour[0] to be hardcoded to 1, but it should be any
On Wed, Nov 04, 2015 at 12:51:52PM -0500, Tom Lane wrote:
> As for the second part, I had to look up Fisher-Yates ;-) but after
> having read Wikipedia's entry about it I think this is a good change.
> The code's shorter and more efficient, and it should mathematically
> provide an equally-unbiase
On Wed, Nov 04, 2015 at 12:51:52PM -0500, Tom Lane wrote:
> Nathan Wagner writes:
> > I have two patches to make the geqo initialization and mutation
> > slightly better.
>
> > The first adjusts the mutation swaps to avoid having to re-pick
> > ties. The second
On Sat, Oct 31, 2015 at 12:08:58PM -0400, Tom Lane wrote:
> Nathan Wagner writes:
> > Second, it would be convenient if there were a make target that would
> > set up a test environment. Effectively do what the 'make check' does,
> > but don't run the tests a
On Sat, Oct 31, 2015 at 08:03:59AM +0100, Robert Haas wrote:
> +1. FWIW, I'm willing to review some patches for this CommitFest, but
> if the committers have to do first-round review as well as
> committer-review of every patch in the CommitFest, this is going to be
> long, ugly, and painful. We
On Wed, Oct 28, 2015 at 02:42:19PM +0100, Robert Haas wrote:
> On Wed, Oct 28, 2015 at 2:17 PM, Andres Freund wrote:
> >> I use COPT for this purpose.
> >
> > Unless I miss something you can't just pass that to configure though,
> > right? I.e. it has to be passed to each make invocation?
>
> Wha
On Tue, Oct 27, 2015 at 01:52:11PM +, Nathan Wagner wrote:
> On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote:
> > Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be
> > cool.
>
> Patch attached...
This isn&
On Wed, Oct 28, 2015 at 08:17:25AM +1300, Gavin Flower wrote:
> You trying to get PostgreSQL banned in France??? :-)
>
> When I was learning French many years ago, I was told that the French
> consider their fortnight to be 15 days!!!
What, it's a "fortnight", not a "quinzaine".
You have no ide
On Tue, Oct 27, 2015 at 12:04:55PM -0500, Merlin Moncure wrote:
> On Tue, Oct 27, 2015 at 8:52 AM, Nathan Wagner wrote:
> > On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote:
> >> Aw, you're no fun. select '1 fortnight'::interval => '14 days
On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote:
> Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be cool.
Patch attached...
:)
% psql -p 5433 -d template1 -h localhost
psql (9.4.5, server 9.6devel)
WARNING: psql major version 9.4, server major version 9.6.
On Tue, Oct 20, 2015 at 10:39:55AM -0700, Joshua D. Drake wrote:
> So where are we at on this?
Well, I can't speak to where we are, but my system is up, running, and
seems to work well, It even attracts a few visitors.
I have been meaning to write a triage interface, but I have been stuck
doing
On Wed, Oct 07, 2015 at 03:06:50PM -0400, Stephen Frost wrote:
> * Nathan Wagner (nw...@hydaspes.if.org) wrote:
> > I have added full text searching to my tracker. I only index the first
> > 50 KB of each message. There's apparently a one MB limit on that
> > anyway, w
I have added full text searching to my tracker. I only index the first
50 KB of each message. There's apparently a one MB limit on that
anyway, which a few messages exceed. I figure anything important is
probably in the first 50KB. I could be wrong. I could re-index fairly
easily. It seems to
On Tue, Oct 06, 2015 at 01:17:48PM -0400, Bruce Momjian wrote:
> I do think we rushed to choose a tracker a little too quickly.
Have we chosen one?
> Let me explain, from a high level, what a new tracker will change in
> our workflow.
[snip]
I won't quote your whole message, which I essentiall
On Tue, Oct 06, 2015 at 10:57:42AM -0700, Josh Berkus wrote:
> On 10/06/2015 10:17 AM, Bruce Momjian wrote:
> > Therefore, our current default behavior is to ignore user reports,
> > unless someone takes an action to reply, record, or retain the email for
> > later review. What a tracker does is
On Tue, Oct 06, 2015 at 12:04:11PM -0500, Jaime Casanova wrote:
> I like how this page is looking now, good work.
Thank you.
> Now, AFAIU from previous mails part of the reason to have a bug
> tracker is to make easy to know when a bug was fixed. Which should be
> interpreted as: which versions
So, in order to do some clean up and see how my pgbugs page
(https://granicus.if.org/pgbugs/) might actually work I've been going
through bugs and marking their status. A lot of questions arise.
A lot of the reports aren't bugs at all, but requests for help. My
guess is that the users either don
I don't have the original message for this thread, so I arbitrarily picked a
message to reply to.
Since what has been asked for is a bug *tracker*, and we already have a bugs
mailing list, I put together something.
I downloaded the archives for pgsql-bugs, and fed them into a database. This
part
On Sun, Oct 04, 2015 at 04:30:49PM -0700, Josh Berkus wrote:
> That would be the key part, wouldn't it? Nice that you have [code to
> store and parse email messages].
Yeah. It actually made most of the work pretty easy. It's available
with a bunch of other code at https://pd.if.org/git/ if anyo
I don't have the original message for this thread, so I arbitrarily picked a
message to reply to.
Since what has been asked for is a bug *tracker*, and we already have a bugs
mailing list, I put together something.
I downloaded the archives for pgsql-bugs, and fed them into a database. This
part
against commit 49124613f134b04594b1a5c46368eb0a5db16d4b
(i.e. tip of master as of when I re-made the diff).
On my system the patches pass a ./configure; make; make check
--
nw
>From c7f3c7cc37f943481b2358149210789be3d39ee9 Mon Sep 17 00:00:00 2001
From: Nathan Wagner
Date: Sun, 21 Sep 2014 09:30
> However, by realizing that the bounds on the ranges have a linear ordering
> one can speed this up to 0(m) using windowing functions on common table
> expressions.
>
> So what I am proposing is formalizing this optimization into a class of data
> types, that will hide the implementation details.
On Mon, Sep 10, 2012 at 04:23:00PM -0700, David E. Wheeler wrote:
> Well given that OSSP seems to be abandon ware (no activity since July
> 2008), it might be time to dump it in favor of something else.
Perhaps this would be a good time to bring up my uuid code again. I've
got a module for uuid s
e the
index, or my high selectivity quals would use a table scan, either of
which would be wrong.
I guess I could wipe out the stats and get some real numbers tonight,
but I can't see how the planner would be able to distinguish *without*
mcv's...
Best,
Nathan
--
Sent via pgsql-ha
argument more compelling.
Sorry to be difficult,
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Feb 29, 2012 at 2:43 PM, Tom Lane wrote:
> Nathan Boley writes:
>> On Wed, Feb 29, 2012 at 12:39 PM, Tom Lane wrote:
>>> I am starting to look at this patch now. I'm wondering exactly why the
>>> decision was made to continue storing btree-style statis
AY[ 1, 2, 3, 1000];
would no longer use an index. Is that correct?
Are you suggesting removing MCV's in lieu of MCE's as well?
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
is on a 5 disk SATA software raid 5.
Is there anything else that would be useful to know? ( Sorry, this
isn't a subject that I'm very familiar with )
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
>> Version of patch with few more comments and some fixes.
>
> Where are we on the idea of better statistics for arrays?
I need to finish reviewing the patch: I'll try to send in something
tomorrow night. So far it looks good.
Best,
Nathan
--
Sent via pgsql-hackers mailing li
On Sat, 26 Nov 2011 22:36:15 +0200, Peter Eisentraut wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near "foo"
but running
psql < foo.sql does not. I suggest w
> Rebased with head.
FYI, I've added myself as the reviewer for the current commitfest.
Best,
Nathan Boley
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alex? ), with the promise of a new version with
improved comments.
Best,
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Actually, not MCV slot is used but MCELEM. It is a different slot. ps_stats
> view map both into same fileds.
Yes, you're right. I am sorry about the error.
> Surely, non-standard use of histogram slot
> should be avoided.
Agreed.
Best,
Nathan
--
Sent via pgsql-hackers ma
at matters, why not just
perform the calculation in log space?
2) compute_array_stats is really long. Could you break it up? ( I know that
the other analyze functions are the same way, but why continue in
that vein? )
Best,
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
work for every possible predicate.
Best,
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
mp; C from a bitmap scan into WHERE A && (B INTERSECT C), a
simple index scan. In the union case ( even if we had a type that
supported disjoint intervals), I doubt we would ever make that
transformation because the index will probably still be over connected
intervals.
So, +1 for keeping it
On Wed, Jan 19, 2011 at 6:35 PM, Florian Pflug wrote:
> On Jan20, 2011, at 02:41 , Nathan Boley wrote:
>>>> If you think about it, it's a bit ridiculous to look at the whole table
>>>> *just* to "estimate" ndistinct - if we go that far why dont we just
&g
ee how well similar
heuristics work in the multiple column case. I am worried that if the
initial plan is too complicated then nothing will happen and, even if
something does happen, it will be tough to get it committed ( check
the archives for cross column stat threads - there are a lot ).
Best,
Nathan Boley
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ated. Improving the ndistinct estimator could
significantly improve the estimates of ndistinct ( in the quadratic
loss sense ) while only marginally improving the plans.
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
re seems to support me )
pounding away at the ndistinct estimator seems like a dead end. If you
think about it, it's a bit ridiculous to look at the whole table
*just* to "estimate" ndistinct - if we go that far why dont we just
store the full distribution and be done with it?
>>>> print int(1e+01)
> 10
>>>>
>
That isn't building an integer: it is creating a float and casting to an int.
try:
int( 1e100 )
Best,
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
t copulas [2] ( FWIW I think that Josh Tolley was
looking at this a couple years back ).
Best,
Nathan
[1] http://en.wikipedia.org/wiki/Classification_and_regression_tree
[2] http://en.wikipedia.org/wiki/Copula_%28statistics%29
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
n the values of a whole boat-load of GUCs...
Well, then doesn't the 'proper' number of buckets depend on a whole
boat-load of GUCs...
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s, except the queries
of interest are inequality rather than equality selections.
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
E OVER timestamp (UNIT = '1m');
>
> All of the stuff about defining + and - is hidden from the user - it's
> part of the type interface, which is pre-created.
>
The disadvantage is that it does not permit irregularly spaced units.
-Nathan
--
Sent via pgsql-hackers mailing
On Wed, 03 Feb 2010 14:41:13 -0500, Tom Lane wrote:
> Indeed it is, which is one of the reasons to be cautious with changing
> it. We've been telling people to move away from \' for a long time,
> but actually flipping the switch that will make their apps insecure
> is not something to do on the
sday, and then 'Returned with Feedback'
will at least be factual.
Best,
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
C, but I have
often found pl/python to be very unwieldy. For this reason I often
use pl/perl or pl/pgsql for problems that, outside of postgres, I
would always use python. From the documentation, this patch seems like
an enormous step in the right direction.
-Nathan
--
Sent via pgsql-hackers maili
> Right, I don't think strings are any more or less countable than integers.
> (and yes, it's a bit OT).
Well, if I remember my algebra, I think the issue is that integers are
locally finite whereas strings are not ( assuming standard orderings,
of course ).
-Nathan
--
Sent v
6,2), [1,2.99] UNION
[3,5] should be [1,5].
FWIW, I would answer yes, no, yes to those three questions.
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that this is the best approach, then I will
do a more comprehensive review.
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
if this has
already been discussed, but would this mean that I need to choose
whether pl/python is built against Python 2.* or Python 3.*?
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;
Non overlapping time intervals is one use case - think about room
scheduling. I personally want to use it to ensure the consistency of
genomic annotations.
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
with 100
completely random values in colA ( ie 1, 22, 47, 89, 91, 92, 107, ...
) there is not a whole lot we can do besides storing a list of all of
those values. We could maybe use the ratio of classes to improve the
average plan choice, but you would still get a lot of bad plans.
Could anyone pro
On Mon, Jun 29, 2009 at 3:43 PM, Tom Lane wrote:
> David Fetter writes:
>> On Mon, Jun 29, 2009 at 01:28:01PM -0700, Nathan Boley wrote:
>>> ... They dismiss
>>> singular value decomposition and the discrete wavelet transform as
>>> being too parametric ( w
ll of the intersecting
boxes ). But I am sure that there are much better ways ( nested
containment lists perhaps? ).
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
when to create a new box by a statistical test ( maybe
homogeneity of means? ) ( also, the same holds for the outliers ).
Finally, this creates the partition but ( AFAICT ) it doesn't describe
a method for locating the histogram estimate given a point ( although
that doesn't seem too diffic
> Surely the most important point in the OP was that ineqsel does not
> correctly binary search in the presence of duplicates.
>
It would have been if I were correct :-( .
Looking at it again, that was from a bug in my code. Thanks for your
time, and sorry about the noise.
-Nathan
--
alyze is...
Thanks for the response,
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ristic to cut off the MCV list at some
> shorter length (ie, more than 1% in this example) if it seems not
> worthwhile to keep the last entries. See lines 2132ff (in CVS HEAD)
> in analyze.c.
Given an increase in the default stats target, limits like the 25% are
exactly what I think
then any values that occupy
more than 1% of the table will be mcv's regardless - why force a value
to be an mcv if it only occupies 0.1% of the table? That just bloats
pg_statistic and slows down joins unnecessarily.
I'll submit a patch for 8.5 and then, hopefully, some simple
benchmarks ca
I guess this is a bit off topic for the middle of a commit fest though.
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
c. That could be used for rather accurate
> cardinality estimation of "between" cases, while keeping number of entries
> in "MCV" list small.
>
I suggested this earlier (
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00353.php ).
If there's interest, I&
__name, _readable, _lineNumber, _setsParameter ) if you dont
want them to be accessed directly.
Hope my comments are useful! Thanks again for writing this.
-Nathan
P.S. I'd be happy to officially review this if it gets to that.
--
Sent via pgsql-hackers mailing list (pgsql-h
1 - 100 of 334 matches
Mail list logo
