y a
mistake, and the user should be informed.
By the way, what does this have to do with canonical functions? This
seems more like a constructor issue, and there is already a
zero-argument constructor to make empty ranges.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsq
On Fri, 2011-11-18 at 13:32 +0100, Florian Pflug wrote:
> That information, however, *is* already contained in the canonical
> functions, because those function know that (2,3) are empty as an integer
> range, but non-empty as a float range.
Very good point. Thank you.
Regards,
to work. Seeing it as useful in the context of
range_adjacent might mean that it's useful elsewhere, too, so now I'm
leaning toward supporting [3,3) as an empty range.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
don't seem to cause problems, but the utility is also very
minor.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nvolve generating values that might overflow.
I think we had that discussion before, and Florian brought up some good
points (both then and in a reply now). Also, Robert wasn't convinced
that '[]' is necessarily better for discrete ranges:
http://archives.postgresql.org/p
n either direction, just an
observation.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t be a constraint hierarchy; e.g. a step size 100 is based on a
step size of 10 which is based on numeric?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
h conceptually, though I'm still working through the
details.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that you've committed the flag for
"contains empty ranges".
However, it still sounds like a useful improvement to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
A built-in textrange type would have to have collation "C", right? Do
you think that would be useful to enough people?
One that I'd like to see is an IP address type, but that's complicated
because inet and cidr support netmasks.
Regards,
Jeff Davis
--
Sent via
sidered. Should it be?
* You defined get/set_range_contain_empty, but didn't use them. I think
this was a merge error, but I removed them. So now there are no changes
in rangetypes.c.
Regards,
Jeff Davis
range_gist_cleanup.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers
ng the common entries does seem like a smaller
version of the original problem. Thoughts?
Thank you for the helpful comments! It took me a while to work through
the logic, but I would have been lost completely without the comments
around the double sorting split.
Regards,
Jeff Davis
*
lly dealing with widely varying range sizes, etc. My approach
really only tackled the simple (and hopefully common) case when the
ranges are about the same size.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
g room for the future?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
overwrite your
previous (good) backup with a bad one. The more complicated we make the
verification process, the less workable that becomes.
I vote for a simple way to calculate the checksum -- fixed offsets of
each page (of course, it would need to know the page size), and a
standard checksum algor
s that support CRCs are more like ZFS than ext3. They do
all writes to a new location, thus fragmenting the files. That may be a
good trade-off for some people, but it's not free.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
eue depth if there's some weird i/o scheduling going on.
That would also depend on how many disks you have and what configuration
they're in, right?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
out).
3. Attack hint bits problem.
If (1) and (2) were complete, we would catch many common types of
corruption, and we'd be in a much better position to think clearly about
hint bits, double writes, etc.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
On Tue, 2011-12-27 at 16:43 -0600, Merlin Moncure wrote:
> On Tue, Dec 27, 2011 at 1:24 PM, Jeff Davis wrote:
> > 3. Attack hint bits problem.
>
> A large number of problems would go away if the current hint bit
> system could be replaced with something that did not requir
with columns that are
referred to as a group (e.g. a=1 AND b<20).
Regards,
Jeff Davis
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so t
On Mon, 2007-03-19 at 21:24 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > We can already keep stats for a functional index. Is there a reason we
> > can't keep stats for a multi-column index?
>
> The questions that need to be answered
x27;s
already solved with known algorithms?
Regards,
Jeff Davis
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can g
mited
accuracy to n_distinct. So there may be a reason to store more
information, but I don't know what we'd store. Do we have reports of bad
estimates by the planner in this situation?
Regards,
Jeff Davis
---(end of broadcast)--
ommunity/lists/
You may find PostgreSQL users that speak your native language and can
help you communicate with the PostgreSQL developers, who are
predominantly English-speaking.
We're happy to see that you're interested in helping PostgreSQL!
Regards,
Jeff Davis
---
n of Simon's patch that I used did not apply
cleanly to 8.2.3, but the only problem appeared to be in copy.c, so I
went ahead with the tests. If this somehow compromised the patch, then
let me know.
Regards,
Jeff Davis
---(end of broadcast)---
ally
accessible.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
On Tue, 2007-04-03 at 10:01 +0100, Simon Riggs wrote:
> On Mon, 2007-04-02 at 16:14 -0700, Jeff Davis wrote:
>
> > The results are very positive and quite conclusive.
>
> Can we show some summary results?
I should be able to make some graphs today.
> I'm happy that t
t's two big tables, a join would be a major operation. I don't
think it would even choose a hash join in that situation, right?
To summarize, in the next round of testing, I will
* disable sync_seqscan_offset completely
* use recycle_buffers=0 and 32
* I'll still test against 8.
7;ll give 2 and 3 some more thought,
> and take a closer look at the scan-resistant scans patch. Any comments
> and ideas are welcome, of course..
>
Yes. I'll also try to address the other issues in your email. Thanks for
your comments.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze is your friend
this
> > if down the road we find that it's a bottleneck.
>
> Another trick you could do is to use acquire the lock conditionally when
> updating it. But I doubt it's a problem anyhow, if we put some sane
> lower limit in there so that it
On Wed, 2007-05-02 at 20:58 +0100, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > What should be the maximum size of this hash table?
>
> Good question. And also, how do you remove entries from it?
>
> I guess the size should somehow be related to number of backends.
On Wed, 2007-05-02 at 23:59 +0100, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > On Wed, 2007-05-02 at 20:58 +0100, Heikki Linnakangas wrote:
> >> Jeff Davis wrote:
> >>> What should be the maximum size of this hash table?
> >> Good question. And
te rare that more than 10 different
big relations are being scanned at once, and I don't know how much of a
gain a hash table is when there are (in all but exceptional cases) only
a few entries.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
to more relations being concurrently
scanned I could use Heikki's recommendation of a dynamic hash table.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
l go with that
> > instead of the list-only approach. The only reason I suggested the list-
> > only approach was to see if the hash table was really gaining anything
> > for us. In practice, it will be quite rare that more than 10 different
> > big relations are being scanned at
n of data is different. The
mycorr_10 table has tuples in which a and b are > 15.9M spread all
throughout. mycorr_100 has them all collected together at the end of the
physical file. Less disk seeking.
You can test this by doing a CLUSTER on both tables and run the same
queries again.
Regards,
stand it), which doesn't
seem like a problem to me.
Is there a reason this isn't a part of 8.3, or was it just forgotten?
Regards,
Jeff Davis
---(end of broadcast)---
TIP 4: Have you searched our list archives?
;s an area of research for the future, but for now I just want
to concentrate on the most important aspect of my patch: the
synchronized scanning ( #2 in your list ).
Regards,
Jeff Davis
---(end of broadcast)---
TIP 9: In versions below 8.0,
tch only reports every 16
pages, so 32KB (=4 pages) is not going to work for sync scans (I suppose
only testing will tell).
Regards,
Jeff Davis
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
th 8 buffers, that means each scan must report every 4 pages at
most (and maybe every page), which increases lock contention (the new
design Heikki and I discussed requires a lock every time a backend
reports its position).
Regards,
Jeff Davis
---(end of broadcast)-
ved and the reviewers are satisfied, I'd like to
work on it.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
so that administrators could notice and correct the
problem.
Are you referring to the size of the xip array being a problem? Would it
help to tie the size of the xip array to max_connections? I understand
that max_connections might be greater on the master, but maybe something
sim
the old global snapshot,
> so time wouldn't advance for them until the number of concurrent
> transactions decreases again.
That sounds better than locking out all reads. Perhaps still a warning
in the logs though. If the situation you describe happens, the
administr
e that ID for a real transaction itself. However, I don't see a real
problem on the slave because it would only be used for the purpose of
the snapshot we need at that moment.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 1:
ave a
wider distribution of data, GIT is probably better, although you have to
keep some degree of clustering (HOT may help with that).
Heikki is the authority on GIT, so I'm including him in the CC so he can
correct me :)
Regards,
Jeff Davis
*: I'm not 100% sure I'm using
case in GIT. We could effectively do both.
>
The bigger difference that I see is that GIT doesn't just group together
ranges of keys, it also groups by heap page number (or a small range of
page numbers, as Simon pointed out).
Regards,
Jeff Davis
r.
>
This sounds useful for read-only or read-mostly tables.
However, it also sounds a little dangerous. If you test your application
performance, but not thoroughly enough, you might end up with a surprise
when going into production.
Regards,
Jeff Davis
es that we should
consider, and we should consider them carefully. However, I don't think
that the current behavior is correct, for the same reason that I don't
think that "February 31st, 2007" should be allowed in a date column.
Regards,
Jeff Davis
---
ECURITY DEFINER function.
That seems a little awkward, because to avoid a security race condition,
you'd have to wrap the CREATE/ALTER in a transaction block. However, we
already have a similar situation with creating a security definer
function and then revoking access, so maybe
RENT.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
_path=foo" to the input of psql, i.e.:
$ echo "SET search_path=foo;" | cat module_install.sql | psql my_db
..or
$ psql my_db
=> SET search_path=foo;
=> \i module_install.sql
Regards,
Jeff Davis
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
l
But the CREATE FUNCTION page has a section titled "Writing SECURITY
DEFINER Functions Safely", so I think it's useful to have it there, too.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 3: Have you checked our ext
be
easy to get a lot of the benefit by just having a utility that could
discard useless contents that are left over from a previously-recycled
file, and then could just reconstruct it later with zeros.
Regards,
Jeff Davis
---(end of broadcast)---
On Thu, 2007-09-06 at 19:23 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > On Thu, 2007-09-06 at 12:08 +0100, Heikki Linnakangas wrote:
> >> With file-based log shipping, you can get down to 1 second, by using the
> >> archive_timeout sett
tes after it. Similar strange things
happen if you have a E'\134' (backslash) somewhere in the string.
However, I have no doubt that there are people who use the first
strategy anyway, and the proposed change would break that for them.
There may be more issues, too.
Regar
On Sun, 2007-09-09 at 17:09 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > Currently, you can pass a bytea literal as either: E'\377\377\377' or
> > E'\\377\\377\\377'.
>
> > The first strategy (single backslash) is not c
Sounds reasonable to me.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
I am still worried about COPY.
If it's done in the scanner it should still accept things like:
E'\\377\\000\\377'::bytea
right?
I think the concern is when they use only one slash, like:
E'\377\000\377'::bytea
which, as I mentioned befor
_euc_jp);
>
> Without using convert(), he will get random order of data. This is
> because Kanji characters are in random order in UTF-8, while Kanji
> characters are reasonably ordered in EUC_JP.
Isn't the collation a locale issue, not an encoding issue? Is there a
ja_JP.UTF-8 t
is the
source of the problem.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze is your friend
ERROR: invalid byte sequence for encoding "UTF8": 0xbd
Regards,
Jeff Davis
test=> select
asses the strings to strcmp().
Are you saying that we should not remove convert() until we can support
multiple locales in one database?
If we make convert() operate on bytea and return bytea, as Tom
suggested, would that solve your use case?
Regards,
Jeff Davis
--
lso
"One way to use multiple encodings safely is to set the locale to C or
POSIX during initdb, thus disabling any real locale awareness."
Regards,
Jeff Davis
---(end of broadcast)---
TIP 9: In versions below 8.0, the pl
On Tue, 2007-09-11 at 14:48 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > On Mon, 2007-09-10 at 23:20 -0400, Tom Lane wrote:
> >> It might work the way you are expecting if the database uses SQL_ASCII
> >> encoding and C locale --- and I'
uses "-w"). I don't think that's the expected result, and it's not
intuitive to find the cause of the problem.
I think the inconsistency between server port number and socket
directory is less than ideal. However, I also don't feel very strongly
about
gt; Can you throw any light on those questions?
> 1. Why doesn't the subselect work?
>
You could do something like:
SELECT * FROM c AS c1, c AS c2 WHERE ARRAY[c1.col1] <@ ANY(SELECT c2.col2);
Regards,
Jeff Davis
---(end of broadcast)-
On Fri, 2007-10-05 at 12:29 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > You could do something like:
> > SELECT * FROM c AS c1, c AS c2 WHERE ARRAY[c1.col1] <@ ANY(SELECT c2.col2);
>
> Good point --- actually he could convert it back to the
whole
> system is healthy gets a lot more complicated if we stop sending
> empty WAL files.
>
> Could this at least be a configurable option?
>
A good point.
Keep in mind that even in the current system, your configuration is
variable based on the checkpoint_timeout setting.
Reg
On Fri, 2007-10-26 at 18:47 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > What's happening is that you have a checkpoint_timeout of 5 minutes, and
> > that checkpoint must write a checkpoint record in the WAL, prompting the
> > archiving.
>
base would not advance that location at all,
and I'm still trying to understand Tom's proposal well enough to know
whether that would be true or not.
If this doesn't get changed, I think we should archive every
archive_timeout seconds, rather than
MAX(archive_timeout,check
ine for me, but it would be nice if there was something that could be
released that anyone could use, including non-english installations.
Also, did you publish your pg_clearxlogtail program anywhere? I think
that would be helpful to many people, but I don't see it on pgfoundry.
Rega
On Mon, 2007-10-29 at 14:20 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > One minor thing: I think it's still dependent on locale though, because
> > the output of pg_controldata is locale-dependent, right? It would work
> > fine for me, b
to
me.
2) Change to autovacuum to FREEZE on the forced autovacuum to prevent
wraparound.
3) Use multiple bits per visibility map
4) Have multiple types of visibility maps
The more I think about the visibility map, the more I think it will be a
huge win for PostgreSQL. It's especially nice
> set to FrozenXid if the group of pages are totally frozen.
>
Wouldn't that still require WAL traffic? Otherwise how can you guarantee
that the FrozenXid hits disk before TruncateCLOG truncates the old xmin
away?
Regards,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze is your friend
- Tables that are heavily updated - any case where the index entry often
> maps to a non-visible tuple.
>
> Beyond that, yeah, I cannot think of other benefits.
>
What about range queries or sorts?
The correlation of an index to itself is 100% :)
Regards,
Jeff Davis
for testing the beta!
Regards,
Jeff Davis
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
you will need more blocks from the soonest.
I'm still looking into the problem to understand it better, but the
algorithm is in Knuth Vol 3.
I can look at it in more detail, but have you already looked into this
idea? Is there a reason we don't do this currently?
Regards,
Jeff Davi
ed
at once, but if the data really *is* random, we'd want it to degrade
gracefully something resembling the current implementation.
I'm being somewhat vague here because I haven't taken the time to
really understand it. If you think this idea has potential I will look
forecasting comes in:
you preread from the tapes you will actually need tuples from soonest.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
read from each run) to determine the runs
from which we need tuples the soonest.
Then, it prereads the _correct_ data.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze is your friend
be to allow each sub
process to allocate work_mem/P where P is the degree of parallelization.
However, that somewhat works against our schemes for dynamic run
handling and forecasting, and may lead to more random reading from disk.
Any other scheme I can think of would involve more IPC, which
1p1t" in Ron's
reference above.
These are just my first thoughts, however. There is a lot of existing
research out there that we can look into, and also a lot of tests that
we can run before jumping into this.
I think parallel sorting can be looked into separately from the other
sorting improv
ithout
> degrading performance for existing loads), but that doesn't mean
> impossible. :-)
>
You don't even need multiple cores to achieve a speedup, according to
Ron's reference.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
ach file into a priority queue.
>
> Then, emit records from the queue until the priority queue is empty.
>
What is the principle difference between that idea and our existing sort
algorithm?
There's a good explanation in the comment at the top of tuplesort.c.
urrent code takes into account the cost of
having workMem/M too small.
We do want to increase the number of runs that can be merged at once;
that's what dynamic run handling and forecasting are all about. But we
want to avoid unnecessary seeking, also.
Regards,
Jeff Davis
-
; limited by your disk bandwidth, not your cpu speed.
Are you sure that's always the case? My test seemed to indicate that
sorting took longer than it would to read the file from disk.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
sync scans, but I could not
think of any specific areas of the code that would likely be affected.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze is your friend
licit.
But this is not a strong opinion.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
ng it for tables that have been clustered.
That being said, this isn't a strong objection. Having a painless 8.3
release is the top priority, of course.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 4: Have you se
hat this only matters if you are actually running pg_dump
concurrently with another scan, because a scan will reset the starting
point after completing.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ing. We
may implement other large scan strategies in the future.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
for an empty group is NULL, not an empty array. Note that per
> page 66, I'd expect array values in the input to array_agg() not to be
> flattened.
Should there be an inverse operator (a SRF, in this case) that returns a
set from an array?
Regards,
Jeff Davis
---
se together?".
The answer to that question in your example is "very likely", so there
would be no problem.
Is there a reason we don't do this?
Regards,
Jeff Davis
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
dexed. It's also not clear how to interpolate from that the amount of random
> access a given query would perform.
I don't think "clusteredness" has any meaning at all in postgres for an
unindexed column. I suppose a table could be clustered without an index,
but currently there's
ptz;
which is a simple way to get all records where "during" contains the
point in time '2001-05-11 01:01:01'. It's also indexable with GiST,
meaning that query will perform well in a variety of situations.
I'm going to spend some time getting the docs up
oral issues, fully compatible with the relational model. Unlike
> "time travel" kind of approaches.
I second this statement. That's an excellent book, both analytical and
practical. I think my time interval type is fairly faithful to that
approach (although as I said, I really
On Mon, 2008-02-04 at 19:29 +, Simon Riggs wrote:
> On Mon, 2008-02-04 at 10:57 -0800, Jeff Davis wrote:
>
> > I tried bringing this up on LKML several times (Ron Mayer linked to one
> > of my posts: http://lkml.org/lkml/2007/2/9/275). If anyone has an inside
> >
On Sun, 2008-02-03 at 15:56 -0500, Greg Smith wrote:
> On Sun, 3 Feb 2008, Jeff Davis wrote:
>
> > I think what he means by "bitemporal" is what CJ Date, et al., refer to
> > as "fully temporal" (as opposed to semi-temporal), that is, dealing with
>
unt the time the process has been alive, as well, so you
can't just eat memory in a tight loop).
The postgres process will always be killed, and then it will realize
that it didn't alleviate the memory pressure much, and then kill the
runaway process.
Regards,
Jeff Davis
--
On Mon, 2008-02-04 at 20:50 +, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > Also, they use "period" to mean interval, and "interval" to mean
> > duration -- which is wrong, in my opinion; interval already has a well-
> > defined mathematical meanin
901 - 1000 of 1617 matches
Mail list logo
