Tom Lane wrote:
> Nathan Boeger <[EMAIL PROTECTED]> writes:
> > I am trying to compile an app (compiles on *BSD, Linux) but for some
> > reason I cant get it to compile on AIX 4.3.3.3. It seems not to like the
> > libcrypt ??
>
> > ld: 0711-317 ERROR: Undefine
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
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
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
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
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.
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
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
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
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
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
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/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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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&
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/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
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/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
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
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
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
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
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
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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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]
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
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
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
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
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
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
>>>> 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:
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?
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
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
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
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
> 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.
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
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
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
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
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
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
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
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
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
> 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
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
> 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
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
>> 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
nvent the wheel.
Thanks for your time,
Nathan
--
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Got Mole problems? Call Avogadro at 6.02 x 10^23.
On 5/5/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Nathan Buchanan" <[EMAIL PROTECTED]> writes:
> I had the idea of taking the Fourier transform of the waveform and
storing
> the waveform internally that way to reduce storage requirements.
Aside from what Steve sa
add message number to each
subject line in mail? For example like this:
[HACKERS: 12345] Re: Not ready for 8.3
This way, we could always obtain stable (logical) pointer, without
reling on particular archival infrastructure.
This sounds like a good idea to me - though I'm just a lurker on the list.
Nathan
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
> 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
ild the selectivity histogram.
-Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
>>> Right now our
>>> "histogram" values are really quantiles; the statistics_target T for a
>>> column determines a number of quantiles we'll keep track of, and we
>>> grab values from into an ordered list L so that approximately 1/T of
>>> the entries in that column fall between values L[n] and L
> I'm still working my way around the math, but copulas sound better
> than anything else I've been playing with.
I think the easiest way to think of them is, in 2-D finite spaces,
they are just a plot of the order statistics against one another. Feel
free to mail me off list if you have any math
> I still need to go through backend/utils/adt/selfuncs.c
> to figure out exactly how we use the one-dimensional values.
>
Here's a page that helped me figure all this out.
http://www.postgresql.org/docs/8.1/static/planner-stats-details.html
>>
>> 2) Do we want to fold the MCV's into the depende
__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
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&
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
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
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
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
1 - 100 of 334 matches
Mail list logo
