() aggregates keep state which is equal to
{count(X), sum(X), sum(X*X)}
The 'combine' function gets two such 'state' values, while transition
gets 'state' + next value.
I'm inclined to say that 'combinefn == transfn' is a minority case.
--
Tomas Vondrahttp://www.2ndQuadrant.com
On 20.2.2015 02:58, Tom Lane wrote:
Tomas Vondra tomas.von...@2ndquadrant.com writes:
I see the patch only works with the top-level snapshot timestamp,
stored in globalStats, but since 9.3 (when the stats were split
into per-db files) we track per-database timestamps too.
Shouldn't we make
to be connected to that particular database and that should write fresh
stats, so the timestamps should not be very different.
regards
--
Tomas Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
--
Sent via pgsql-hackers mailing
/modules/dummy_seclabel/expected/dummy_seclabel.out
../src/test/modules/dummy_seclabel/sql/dummy_seclabel.sql
I suppose that's not intentional, right?
--
Tomas Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
--
Sent via
On 19.2.2015 03:14, Tomas Vondra wrote:
I've noticed two unrelated files
Meh, should be I noticed the patch removes two unrelated files ...
../src/test/modules/dummy_seclabel/expected/dummy_seclabel.out
../src/test/modules/dummy_seclabel/sql/dummy_seclabel.sql
I suppose that's
On 16.2.2015 03:38, Andrew Gierth wrote:
Tomas == Tomas Vondra tomas.von...@2ndquadrant.com
writes:
Tomas Improving the estimates is always good, but it's not going
to Tomas fix the case of non-NULL values (it shouldn't be all
that Tomas difficult to create such examples with a value whose
a few hash values and all of
them are exactly the same within the first N bits (thus falling into the
first batch), but N+1 bits are different. So the next split would
actually help. But I think we can leave that up to probability, just
like all the hash code.
--
Tomas Vondrahttp
).
Ideas, opinions?
[1] http://linux.die.net/man/2/sbrk
[2] http://linux.die.net/man/2/mmap
--
Tomas Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
diff --git a/src/backend/utils/mmgr/aset.c b/src/backend/utils/mmgr/aset.c
On 15.2.2015 20:56, Heikki Linnakangas wrote:
On 02/15/2015 08:57 PM, Tomas Vondra wrote:
One of the wilder ideas (I mentined beer was involved!) was a memory
allocator based on mmap [2], bypassing the libc malloc implementation
altogether. mmap() has some nice features (e.g. no issues
On 15.2.2015 21:13, Andres Freund wrote:
On 2015-02-15 21:07:13 +0100, Tomas Vondra wrote:
malloc() does that only for allocations over MAP_THRESHOLD, which
is 128kB by default. Vast majority of blocks we allocate are =
8kB, so mmap() almost never happens.
The problem is that mmap
On 15.2.2015 21:38, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2015-02-15 21:07:13 +0100, Tomas Vondra wrote:
On 15.2.2015 20:56, Heikki Linnakangas wrote:
glibc's malloc() also uses mmap() for larger allocations. Precisely
because those allocations can then be handed
easier to understand.
I concur with the concerns that the comments could do with more
work, but haven't attempted to improve them myself.
There were a few comments about this, after the v8 patch, with
recommended comment changes.
regards
--
Tomas Vondrahttp://www.2ndQuadrant.com
1882 on average, so pretty much no difference. Would be
nice if someone else could try this on their machine(s).
regards
--
Tomas Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
diff --git a/src/backend/executor/nodeSubplan.c b
Hi,
seems the CF app uses an invalid e-mail address when sending messages to
pgsql-hackers - I've added a comment to one of the patches and got this:
pgsql-hackers-testing@localhost
Unrouteable address
Maybe that's expected as the CF app is new, but I haven't seen it
mentioned in this
look. Can you share the patches etc. - either here, or maybe
send it to me directly?
regards
Tomas
--
Tomas Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Hi,
On 21.1.2015 09:01, Jeff Davis wrote:
On Tue, 2015-01-20 at 23:37 +0100, Tomas Vondra wrote:
Tom's message where he points that out is here:
http://www.postgresql.org/message-id/20707.1396372...@sss.pgh.pa.us
That message also says:
I think a patch that stood a chance of getting
version of the patch (unless it gets commited with the
comment fixes before that).
--
Tomas Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 25.12.2014 22:28, Tomas Vondra wrote:
On 25.12.2014 21:14, Andres Freund wrote:
That's indeed odd. Seems to have been lost when the statsfile was
split into multiple files. Alvaro, Tomas?
The goal was to keep the logic as close to the original as possible.
IIRC there were pgstat wait
in the future, but
it's impossible to unbreak it ;-)
regards
--
Tomas Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 21.1.2015 00:38, Michael Paquier wrote:
On Wed, Jan 21, 2015 at 1:08 AM, Tomas Vondra
I've tried to reproduce this on my Raspberry PI 'machine' and it's not
very difficult to trigger this. About 7 out of 10 'make check' runs fail
because of 'pgstat wait timeout'.
All the occurences I've
=true unless using a subcontext
Otherwise the v8 patch is exactly the same as v7. Assuming the comments
make it sufficiently clear, I agree with marking this as 'ready for
committer'.
regards
--
Tomas Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote
* cannot verify the name. Must accept the value on faith.
In which situation this happens? Wouldn't it be better to simply
enforce the transaction and fail otherwise?
regards
--
Tomas Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA
two changes, i.e.
* makeMdArrayResult(..., astate-private_cxt)
* move error handling into initArrayResultArr()
* remove element_type from initArrayResultArr() signature
regards
Tomas Vondra
--
Tomas Vondrahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
Hi,
On 23.12.2014 10:16, Jeff Davis wrote:
It seems that these two patches are being reviewed together. Should
I just combine them into one? My understanding was that some wanted
to review the memory accounting patch separately.
On Sun, 2014-12-21 at 20:19 +0100, Tomas Vondra wrote:
That's
On 28.12.2014 00:46, Noah Misch wrote:
On Tue, Dec 23, 2014 at 03:32:59PM +0100, Tomas Vondra wrote:
On 23.12.2014 15:21, Andrew Dunstan wrote:
No, config_opts is what's passed to configure. Try something like:
if ($branch eq 'REL9_0_STABLE')
{
$skip_steps{'pl-install-check
On 31.12.2014 17:29, Andrew Dunstan wrote:
Sorry, I should have tested it. This seems to work:
if ($branch eq 'REL9_0_STABLE')
{
$PGBuild::Options::skip_steps .= ' pl-install-check';
$main::skip_steps{'pl-install-check'} = 1;
}
cheers
Meh, no problem. We've
On 25.12.2014 20:36, Tom Lane wrote:
Yeah, I've been getting more annoyed by that too lately. I keep
wondering though whether there's an actual bug underneath that
behavior that we're failing to see. PGSTAT_MAX_WAIT_TIME is already
10 seconds; it's hard to credit that increasing it still
On 25.12.2014 21:14, Andres Freund wrote:
On 2014-12-25 14:36:42 -0500, Tom Lane wrote:
My guess is that a checkpoint happened at that time. Maybe it'd be a
good idea to make pg_regress start postgres with log_checkpoints
enabled? My guess is that we'd find horrendous 'sync' times.
On 25.12.2014 22:16, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
On 25.12.2014 20:36, Tom Lane wrote:
BTW, I notice that in the current state of pgstat.c, all the logic
for keeping track of request arrival times is dead code, because
nothing is actually looking
On 25.12.2014 22:40, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
The strange thing is that the split happened ~2 years ago, which is
inconsistent with the sudden increase of this kind of issues. So maybe
something changed on that particular animal (a failing SD card causing
I/O stalls
On 26.12.2014 02:59, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
On 25.12.2014 22:40, Tom Lane wrote:
I think that hamster has basically got a tin can and string for an I/O
subsystem. It's not real clear to me whether there's actually been an
increase in wait timeout failures recently
On 23.12.2014 09:19, Noah Misch wrote:
On Sat, Dec 20, 2014 at 07:28:33PM +0100, Tomas Vondra wrote:
On 20.12.2014 19:05, Tom Lane wrote:
Locale cs_CZ.WIN-1250 is evidently marked with a codeset property of
ANSI_X3.4-1968 (which means old-school US-ASCII). That's certainly
wrong. I believe
is
trivial, splitting them not so much.
On Sun, 2014-12-21 at 20:19 +0100, Tomas Vondra wrote:
That's the only conflict, and after fixing it it compiles OK.
However, I got a segfault on the very first query I tried :-(
If lookup_hash_entry doesn't find the group, and there's not enough
memory
On 23.12.2014 15:21, Andrew Dunstan wrote:
No, config_opts is what's passed to configure. Try something like:
if ($branch eq 'REL9_0_STABLE')
{
$skip_steps{'pl-install-check'} = 1;
}
Applied to all three animals.
Tomas
--
Sent via pgsql-hackers mailing list
On 22.12.2014 10:07, Petr Jelinek wrote:
On 21/12/14 18:38, Tomas Vondra wrote:
(1) The patch adds a new catalog, but does not bump CATVERSION.
I thought this was always done by committer?
Right. Sorry for the noise.
(2) The catalog naming (pg_tablesamplemethod) seems a bit awkward
On 22.12.2014 07:36, Tatsuo Ishii wrote:
On 22.12.2014 00:28, Tomas Vondra wrote:
(2) The 'executeStatement2' API is a bit awkward as the signarure
executeStatement2(PGconn *con, const char *sql, const char *table);
suggests that the 'sql' command is executed when 'table' exists
On 22.12.2014 17:47, Alvaro Herrera wrote:
Tomas Vondra wrote:
On 22.12.2014 07:36, Tatsuo Ishii wrote:
On 22.12.2014 00:28, Tomas Vondra wrote:
(8) Also, I think it's not necessary to define function prototypes for
executeStatement2 and is_table_exists. It certainly
On 22.12.2014 18:41, Andres Freund wrote:
On 2014-12-22 18:17:56 +0100, Tomas Vondra wrote:
On 22.12.2014 17:47, Alvaro Herrera wrote:
Tomas Vondra wrote:
On 22.12.2014 07:36, Tatsuo Ishii wrote:
On 22.12.2014 00:28, Tomas Vondra wrote:
(8) Also, I think it's not necessary to define
On 21.12.2014 02:54, Alvaro Herrera wrote:
Tomas Vondra wrote:
Attached is v5 of the patch, fixing an error with releasing a shared
memory context (invalid flag values in a few calls).
The functions that gain a new argument should get their comment updated,
to explain what the new argument
Hi,
On 18.12.2014 13:14, Petr Jelinek wrote:
Hi,
v2 version of this patch is attached.
I did a review of this v2 patch today. I plan to do a bit more testing,
but these are my comments/questions so far:
(0) There's a TABLESAMPLE page at the wiki, not updated since 2012:
On 2.12.2014 06:14, Jeff Davis wrote:
On Sun, 2014-11-30 at 17:49 -0800, Peter Geoghegan wrote:
On Mon, Nov 17, 2014 at 11:39 PM, Jeff Davis pg...@j-davis.com wrote:
I can also just move isReset there, and keep mem_allocated as a uint64.
That way, if I find later that I want to track the
On 21.12.2014 20:19, Tomas Vondra wrote:
However, I got a segfault on the very first query I tried :-(
create table test_hash_agg as select i AS a, i AS b, i AS c, i AS d
from generate_series(1,1000) s(i);
analyze test_hash_agg;
select a, count(*) from test_hash_agg where
Hi,
On 21.12.2014 15:58, Tatsuo Ishii wrote:
On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii is...@postgresql.org wrote:
If we care enough about that case to attempt the vacuum anyway
then we need to do something about the error message; either
squelch it or check for the existence of the
On 20.12.2014 18:13, Pavel Stehule wrote:
2014-12-20 17:48 GMT+01:00 Noah Misch n...@leadboat.com
$ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC
It is Microsoft encoding, - it is not available on Linux
Not true. It is available on Linux, and the regression tests were
running with it for a
On 20.12.2014 17:48, Noah Misch wrote:
On Sat, Dec 20, 2014 at 05:14:03PM +0100, CSPUG wrote:
On 20.12.2014 07:39, Noah Misch wrote:
Buildfarm members magpie, treepie and fulmar went absent on
2014-10-29. Since returning on 2014-11-16, they have consistently
failed with 'initdb: invalid
On 20.12.2014 18:32, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
On 20.12.2014 18:13, Pavel Stehule wrote:
It is Microsoft encoding, - it is not available on Linux
Not true. It is available on Linux, and the regression tests were
running with it for a long time (essentially from
On 20.12.2014 19:05, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
I believe the locale system (at the OS level) works just like before. I
remember I had to manually create the locales while initially setting up
the animals. Then, ~2 months ago something happened (I asssume a yum
update
On 20.12.2014 19:35, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
On 20.12.2014 19:05, Tom Lane wrote:
I am betting that you recreated them differently from before.
And you're probably right. Apparently, I recreated them like this:
$ localedef -v -c -i cs_CZ -f WIN-1250
mailto:the.ap...@gmail.com:
2014-12-16 6:27 GMT+07:00 Tomas Vondra t...@fuzzy.cz
mailto:t...@fuzzy.cz:
Just fast-viewing the patch.
The patch is not implementing the checking for not creating new
context in initArrayResultArr. I think we
Attached is v5 of the patch, fixing an error with releasing a shared
memory context (invalid flag values in a few calls).
kind regards
Tomas Vondra
diff --git a/src/backend/executor/nodeSubplan.c b/src/backend/executor/nodeSubplan.c
index d9faf20..9c97755 100644
--- a/src/backend/executor
On 12.12.2014 14:19, Robert Haas wrote:
On Thu, Dec 11, 2014 at 5:46 PM, Tomas Vondra t...@fuzzy.cz wrote:
Regarding the sufficiently small - considering today's hardware, we're
probably talking about gigabytes. On machines with significant memory
pressure (forcing the temporary files to disk
On 12.12.2014 19:07, Bruce Momjian wrote:
On Fri, Dec 12, 2014 at 10:50:56AM -0500, Tom Lane wrote:
Also, one part of the point of the review mechanism is that it's
supposed to provide an opportunity for less-senior reviewers to
look at parts of the code that they maybe don't know so well, and
On 11.12.2014 16:06, Bruce Momjian wrote:
On Wed, Dec 10, 2014 at 11:00:21PM -0800, Josh Berkus wrote:
I will add:
4. commitfest managers have burned out and refuse to do it again
Agreed. The fun, if it was ever there, has left the commitfest
process.
I've never been a CFM, but from my
On 12.12.2014 22:13, Robert Haas wrote:
On Fri, Dec 12, 2014 at 11:50 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 12.12.2014 14:19, Robert Haas wrote:
On Thu, Dec 11, 2014 at 5:46 PM, Tomas Vondra t...@fuzzy.cz wrote:
Regarding the sufficiently small - considering today's hardware, we're
On 11.12.2014 20:00, Robert Haas wrote:
On Thu, Dec 11, 2014 at 12:29 PM, Kevin Grittner kgri...@ymail.com wrote:
Under what conditions do you see the inner side get loaded into the
hash table multiple times?
Huh, interesting. I guess I was thinking that the inner side got
rescanned for
On 11.12.2014 17:53, Heikki Linnakangas wrote:
On 10/13/2014 01:00 AM, Tomas Vondra wrote:
Hi,
attached is a WIP patch implementing multivariate statistics.
Great! Really glad to see you working on this.
+ * FIXME This sample sizing is mostly OK when computing stats
of benefit as it is, and trying to handle that case would be a lot
more work (we need a way to write the transition values out to disk at a
minimum, and perhaps combine them with other transition values). I also
don't think my patch would interfere with a fix there in the future.
Tomas Vondra
On 11.12.2014 22:16, Robert Haas wrote:
On Thu, Dec 11, 2014 at 2:51 PM, Tomas Vondra t...@fuzzy.cz wrote:
No, it's not rescanned. It's scanned only once (for the batch #0), and
tuples belonging to the other batches are stored in files. If the number
of batches needs to be increased (e.g
On 8.12.2014 02:01, Michael Paquier wrote:
On Sun, Nov 16, 2014 at 3:35 AM, Tomas Vondra t...@fuzzy.cz wrote:
Thanks for the link. I've been looking for a good dataset with such
data, and this one is by far the best one.
The current version of the patch supports only data types passed
On 2.12.2014 02:52, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
On 2.12.2014 01:33, Tom Lane wrote:
What I suspect you're looking at here is the detritus of creation
of a huge number of memory contexts. mcxt.c keeps its own state
about existing contents in TopMemoryContext. So, if we
Hi!
This was initially posted to pgsql-performance in this thread:
http://www.postgresql.org/message-id/5472416c.3080...@fuzzy.cz
but pgsql-hackers seems like a more appropriate place for further
discussion.
Anyways, attached is v3 of the patch implementing the adaptive ndistinct
estimator.
Hi,
back when we were discussing the hashjoin patches (now committed),
Robert proposed that maybe it'd be a good idea to sometimes increase the
number of tuples per bucket instead of batching.
That is, while initially sizing the hash table - if the hash table with
enough buckets to satisfy
Dne 2014-12-02 02:52, Tom Lane napsal:
Tomas Vondra t...@fuzzy.cz writes:
On 2.12.2014 01:33, Tom Lane wrote:
What I suspect you're looking at here is the detritus of creation of
a huge number of memory contexts. mcxt.c keeps its own state about
existing contents in TopMemoryContext. So, if we
Dne 2 Prosinec 2014, 10:59, Tomas Vondra napsal(a):
Dne 2014-12-02 02:52, Tom Lane napsal:
Tomas Vondra t...@fuzzy.cz writes:
Also, this explains the TopMemoryContext size, but not the RSS size
(or am I missing something)?
Very possibly you're left with islands that prevent reclaiming very
Hi all,
while working on the patch decreasing amount of memory consumed by
array_agg [1], I've ran into some strange OOM issues. Reproducing them
using the attached SQL script is rather simple.
[1] https://commitfest.postgresql.org/action/patch_view?id=1652
At first I thought there's some
On 2.12.2014 00:31, Andrew Dunstan wrote:
On 12/01/2014 05:39 PM, Tomas Vondra wrote:
Hi all,
while working on the patch decreasing amount of memory consumed by
array_agg [1], I've ran into some strange OOM issues. Reproducing them
using the attached SQL script is rather simple.
[1
On 2.12.2014 01:33, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
On 2.12.2014 00:31, Andrew Dunstan wrote:
Doesn't this line:
TopMemoryContext: 136614192 total in 16678 blocks; 136005936 free
(500017 chunks); 608256 used
look pretty suspicious?
It certainly looks a bit large
Hi,
Attached is v2 of the patch lowering array_agg memory requirements.
Hopefully it addresses the issues issues mentioned by TL in this thread
(not handling some of the callers appropriately etc.).
The v2 of the patch does this:
* adds 'subcontext' flag to initArrayResult* methods
If it's
Moving to pgsql-hackers, as that's a more appropriate place for this
discussion.
On 27.11.2014 11:26, Maxim Boguk wrote:
FWIW, I got curious and checked why we decided not to implement this
while reworking the stats in 9.3, as keeping an is_dirty flag seems as a
rather
On 26.11.2014 23:26, Peter Geoghegan wrote:
On Wed, Nov 26, 2014 at 2:00 PM, Andrew Dunstan and...@dunslane.net wrote:
The client's question is whether this is not a bug. It certainly seems like
it should be possible to plan a query without chewing up this much memory,
or at least to be able
On 25.11.2014 18:11, Heikki Linnakangas wrote:
On 11/25/2014 06:06 PM, Christoph Berg wrote:
db1 is registered in pg_database, but the directory is missing on
disk.
Yeah, DROP DATABASE cheats. It deletes all the files first, and commits
the transaction only after that. There's this comment
On 21.11.2014 00:03, Andres Freund wrote:
On 2014-11-17 21:03:07 +0100, Tomas Vondra wrote:
On 17.11.2014 19:46, Andres Freund wrote:
The MemoryContextData struct is embedded into AllocSetContext.
Oh, right. That makes is slightly more complicated, though, because
AllocSetContext adds 6 x
On 15.11.2014 22:36, Simon Riggs wrote:
On 16 October 2014 02:26, Jeff Davis pg...@j-davis.com wrote:
The inheritance is awkward anyway, though. If you create a tracked
context as a child of an already-tracked context, allocations in
the newer one won't count against the original. I don't
On 17.11.2014 08:31, Jeff Davis wrote:
On Sat, 2014-11-15 at 21:36 +, Simon Riggs wrote:
Do I understand correctly that we are trying to account for exact
memory usage at palloc/pfree time? Why??
Not palloc chunks, only tracking at the level of allocated blocks
(that we allocate with
On 17.11.2014 18:04, Andres Freund wrote:
Hi,
On 2014-11-16 23:31:51 -0800, Jeff Davis wrote:
*** a/src/include/nodes/memnodes.h
--- b/src/include/nodes/memnodes.h
***
*** 60,65 typedef struct MemoryContextData
--- 60,66
MemoryContext nextchild;/* next
On 17.11.2014 19:46, Andres Freund wrote:
On 2014-11-17 19:42:25 +0100, Tomas Vondra wrote:
On 17.11.2014 18:04, Andres Freund wrote:
Hi,
On 2014-11-16 23:31:51 -0800, Jeff Davis wrote:
*** a/src/include/nodes/memnodes.h
--- b/src/include/nodes/memnodes.h
***
*** 60,65
On 15.11.2014 18:49, Kevin Grittner
If you eliminate the quals besides the zipcode column you get 61
rows and it gets much stranger, with legal municipalities that are
completely surrounded by Madison that the postal service would
rather you didn't use in addressing your envelopes, but they
Dne 13 Listopad 2014, 12:31, Simon Riggs napsal(a):
On 12 October 2014 23:00, Tomas Vondra t...@fuzzy.cz wrote:
It however seems to be working sufficiently well at this point, enough
to get some useful feedback. So here we go.
This looks interesting and useful.
What I'd like to check
Dne 13 Listopad 2014, 16:51, Katharina Büchse napsal(a):
On 13.11.2014 14:11, Tomas Vondra wrote:
The only place where I think this might work are the associative rules.
It's simple to specify rules like (ZIP code implies city) and we
could
even do some simple check against the data to see
to me directly (not through the
pgsql-hackers list). I assume that's not on purpose, so I'm adding the
list back into the loop ...
On 07.11.2014 20:37, Tomas Vondra wrote:
On 7.11.2014 13:19, Katharina Büchse wrote:
On 06.11.2014 11:56, Tomas Vondra wrote:
Dne 6 Listopad 2014, 11:15, Katharina
On 7.11.2014 13:19, Katharina Büchse wrote:
On 06.11.2014 11:56, Tomas Vondra wrote:
Dne 6 Listopad 2014, 11:15, Katharina Büchse napsal(a):
because correlations might occur only in parts of the data. In this case
a histogram based on a sample of the whole table might not get the point
Hi,
Dne 6 Listopad 2014, 11:15, Katharina Büchse napsal(a):
Hi,
I'm a phd-student at the university of Jena, Thüringen, Germany, in the
field of data bases, more accurate query optimization.
I want to implement a system in PostgreSQL that detects column
correlations and creates statistical
Dne 6 Listopad 2014, 11:50, Gavin Flower napsal(a):
Could you store a 2 dimensional histogram in a one dimensional array:
A[z] = value, where z = col * rowSize + row (zero starting index)?
How would that work for columns with different data types?
Tomas
--
Sent via pgsql-hackers mailing
Dne 6 Listopad 2014, 12:05, Gavin Flower napsal(a):
On 06/11/14 23:57, Tomas Vondra wrote:
Dne 6 Listopad 2014, 11:50, Gavin Flower napsal(a):
Could you store a 2 dimensional histogram in a one dimensional array:
A[z] = value, where z = col * rowSize + row (zero starting index)?
How would
On 2.11.2014 22:34, Noah Misch wrote:
On Sun, Nov 02, 2014 at 05:10:25AM +0100, Marko Tiikkaja wrote:
*** a/contrib/pgcrypto/pgp-decrypt.c
--- b/contrib/pgcrypto/pgp-decrypt.c
***
*** 1069,1075 pgp_skip_packet(PullFilter *pkt)
while (res 0)
res =
Dne 30 Říjen 2014, 10:17, David Rowley napsal(a):
On Thu, Oct 30, 2014 at 12:48 AM, Tomas Vondra t...@fuzzy.cz wrote:
Dne 29 Říjen 2014, 12:31, Petr Jelinek napsal(a):
I've not really gotten around to looking at the patch yet, but I'm
also
wondering if it would be simple include allowing
Hi,
while preparing an overview of features new in 9.4, I noticed that while
we provide NOWAIT for the ALTER ... ALL IN TABLESPACE commands, we
don't support that for the 'single object' case. Is that on purpose? I
assume it makes, as with a single object you can't get stuck half-way
through, but
On 30.10.2014 23:19, David G Johnston wrote:
Tomas Vondra wrote
Also, the current phrasing If the NOWAIT option is specified then
the command will fail if it is unable to acquire all of the locks
required immediately. seems a bit ambiguous to me. Maybe it's just
me, but I wasn't sure
Dne 29 Říjen 2014, 10:41, David Rowley napsal(a):
I've not really gotten around to looking at the patch yet, but I'm also
wondering if it would be simple include allowing functional statistics
too.
The pg_mv_statistic name seems to indicate multi columns, but how about
stats on
Dne 29 Říjen 2014, 12:31, Petr Jelinek napsal(a):
On 29/10/14 10:41, David Rowley wrote:
On Mon, Oct 13, 2014 at 11:00 AM, Tomas Vondra t...@fuzzy.cz
The last point is really just unfinished implementation - the
syntax I
propose is this:
ALTER TABLE ... ADD STATISTICS
Dne 27 Říjen 2014, 10:47, Heikki Linnakangas napsal(a):
On 10/26/2014 11:47 PM, Tomas Vondra wrote:
After eyeballing the code for an hour or two, I think CREATE DATABASE
should be fine with performing only a 'partial checkpoint' on the
template database - calling FlushDatabaseBuffers
Dne 27 Říjen 2014, 13:50, Atri Sharma napsal(a):
IMHO writing all the data into a WAL would be the cleanest solution.
Also, what is a small database? I don't think a static value will work,
because the sweet spot between the current approach (forcing two
checkpoints) and writing everything
On 27.10.2014 17:24, Heikki Linnakangas wrote:
On 10/27/2014 03:46 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 10/27/2014 03:21 PM, Tomas Vondra wrote:
Thinking about this a bit more, do we really need a full checkpoint?
That
is a checkpoint of all the databases
On 28.10.2014 00:06, Andrew Dunstan wrote:
On 10/27/2014 07:01 PM, Andres Freund wrote:
On 2014-10-27 18:57:27 -0400, Andrew Dunstan wrote:
On 10/27/2014 05:58 PM, Tomas Vondra wrote:
On 27.10.2014 17:24, Heikki Linnakangas wrote:
I'm also thinking that for wal_level=archive and large
Hi all,
currently, CREATE DATABASE forces an immediate checkpoint (actually, it
forces two, but the time interval is usually rather small). For
traditional deployments this is not a big deal, because creating a
database is a rare event, and may be planned to off-peak times.
However for shared
Hi,
On 16.10.2014 03:26, Jeff Davis wrote:
On Fri, 2014-08-29 at 10:12 -0400, Tom Lane wrote:
What about removing the callback per se and just keeping the
argument, as it were. That is, a MemoryContext has a field of type
size_t * that is normally NULL, but if set to non-NULL, then we
Hi!
On 13.10.2014 09:36, Albe Laurenz wrote:
Tomas Vondra wrote:
attached is a WIP patch implementing multivariate statistics.
I think that is pretty useful.
Oracle has an identical feature called extended statistics.
That's probably an entirely different thing, but it would be very
Hi!
On 9.10.2014 22:28, Kevin Grittner wrote:
Tomas Vondra t...@fuzzy.cz wrote:
The only case I've been able to come up with is when the hash table
fits into work_mem only thanks to not counting the buckets. The new
code will start batching in this case.
Hmm. If you look at the timings
Dne 2 Říjen 2014, 2:20, Kevin Grittner napsal(a):
Tomas Vondra t...@fuzzy.cz wrote:
On 12.9.2014 23:22, Robert Haas wrote:
My first thought is to revert to NTUP_PER_BUCKET=1, but it's
certainly arguable. Either method, though, figures to be better than
doing nothing, so let's do something
On 12.9.2014 18:49, Robert Haas wrote:
On Fri, Sep 12, 2014 at 8:28 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Sep 11, 2014 at 5:57 PM, Tomas Vondra t...@fuzzy.cz wrote:
Attached is the patch split as suggested:
(a) hashjoin-nbuckets-v14a-size.patch
* NTUP_PER_BUCKET=1
801 - 900 of 1369 matches
Mail list logo
