Hi!
Studying this question little more I found that current approach of range
indexing can be dramatically inefficient in some cases. It's not because of
penalty or split implementation, but because of approach itself. Mapping
intervals to two-dimensional space produce much better results in case
On Tue, Dec 20, 2011 at 00:26, David E. Wheeler wrote:
> On Dec 18, 2011, at 4:41 AM, Magnus Hagander wrote:
>
>> We can hopefully get around this for the extensions in contrib (and
>> reasonably well has already), but few large companies are going to be
>> happy to go to pgxn and download an exte
>Would this be alleviated by setting stats_temp_dir to point to a ramdisk?
I am not aware how to do this. I am using a windows server OS.
The conf file has the entry : #stats_temp_directory = 'pg_stat_tmp'
What do I change it to? Please elucidate.
--
View this message in context:
http://postgre
On Tue, Dec 20, 2011 at 06:00, Robert Haas wrote:
> On Mon, Dec 19, 2011 at 6:26 PM, David E. Wheeler
> wrote:
>> +1, though I think the core type will at least need some basic operators and
>> indexing support.
>
> And I'm willing to do that, but I thought it best to submit a bare
> bones patc
2011/12/20 Tomas Vondra :
> Hello everybody,
>
> this patch adds two counters to pg_stat_database to track temporary
> files - number of temp files and number of bytes. I see this as a useful
> feature, as temporary files often cause a lot of IO (because of low
> work_mem etc.). The log_temp_files
On Tue, Dec 6, 2011 at 19:06, Robert Haas wrote:
> On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
> wrote:
>> On 06-12-2011 13:11, Robert Haas wrote:
>>> On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander wrote:
I've been considering similar things, as you can find in the archives,
On 20 Prosinec 2011, 11:20, Magnus Hagander wrote:
> 2011/12/20 Tomas Vondra :
>>
>> I haven't updated the docs yet - let's see if the patch is acceptable at
>> all first.
>
> Again, without having reviewed the code, this looks like a feature
> we'd want, so please add some docs, and then submit it
On Tue, Dec 20, 2011 at 11:45, Tomas Vondra wrote:
> On 20 Prosinec 2011, 11:20, Magnus Hagander wrote:
>> 2011/12/20 Tomas Vondra :
>>>
>>> I haven't updated the docs yet - let's see if the patch is acceptable at
>>> all first.
>>
>> Again, without having reviewed the code, this looks like a feat
Hi!
On Wed, Nov 16, 2011 at 1:43 AM, Nathan Boley wrote:
> FYI, I've added myself as the reviewer for the current commitfest.
>
How is going review now?
--
With best regards,
Alexander Korotkov.
Hackers,
For better GiST indexing of range types it's important to have real-life
datasets for testing on. Real-life range datasets would help to proof (or
reject) some concepts and get more realistic benchmarks. Also, it would be
nice to know what queries you expect to run fast on that datasets.
On 20-12-2011 07:27, Magnus Hagander wrote:
> On Tue, Dec 6, 2011 at 19:06, Robert Haas wrote:
>> On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
>> wrote:
>>> On 06-12-2011 13:11, Robert Haas wrote:
On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander
wrote:
> I've been cons
On Mon, Dec 19, 2011 at 15:50, Greg Smith wrote:
> On 12/18/2011 07:31 AM, Magnus Hagander wrote:
>>
>> * I restructured the if statements, because I had a hard time
>> following the comments around that ;) I find this one easier - but I'm
>> happy to change back if you think your version was more
On Tue, Dec 20, 2011 at 1:14 AM, Nikhil Sontakke wrote:
> Agreed. I just tried out the scenarios laid out by you both with and without
> the committed patch and AFAICS, normal inheritance semantics have been
> preserved properly even after the commit.
No, they haven't. I didn't expect this to br
Is there any reason why the setting synchronize_seqscans is in the
section "version/platform compatibility" in postgresql.conf? Is it
just because nobody could find a better place for it? ;) It seems a
bit wrong to me...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-
On 12/20/2011 05:13 AM, pratikchirania wrote:
Would this be alleviated by setting stats_temp_dir to point to a ramdisk?
I am not aware how to do this. I am using a windows server OS.
The conf file has the entry : #stats_temp_directory = 'pg_stat_tmp'
What do I change it to? Please elucidate.
On Mon, Dec 19, 2011 at 2:44 PM, Kevin Grittner
wrote:
> I was thinking that we would warn when such was found, set hint bits
> as needed, and rewrite with the new CRC. In the unlikely event that
> it was a torn hint-bit-only page update, it would be a warning about
> something which is a benign
On Tue, Dec 20, 2011 at 8:35 AM, Magnus Hagander wrote:
> Is there any reason why the setting synchronize_seqscans is in the
> section "version/platform compatibility" in postgresql.conf? Is it
> just because nobody could find a better place for it? ;) It seems a
> bit wrong to me...
Presumably t
from postgresql.conf.sample:
#replication_timeout = 60s # in milliseconds; 0 disables
Seconds or milliseconds? I would suggest we just remove the "in
milliseconds", and instead say "timeout for replication connections; 0
disables".
--
Magnus Hagander
Me: http://www.hagander.net/
Work: h
These days we have pause_at_recovery_target, which lets us pause when
we reach a PITR target. Is there a particular reason we don't have a
way to pause at end of recovery if we *didn't* specify a target -
meaning we let it run until the end of the archived log? While it's
too late to change the tar
On Tue, Dec 20, 2011 at 14:38, Robert Haas wrote:
> On Tue, Dec 20, 2011 at 8:35 AM, Magnus Hagander wrote:
>> Is there any reason why the setting synchronize_seqscans is in the
>> section "version/platform compatibility" in postgresql.conf? Is it
>> just because nobody could find a better place
On Tue, Dec 20, 2011 at 02:41:54PM +0100, Magnus Hagander wrote:
> On Tue, Dec 20, 2011 at 14:38, Robert Haas wrote:
> > On Tue, Dec 20, 2011 at 8:35 AM, Magnus Hagander
> > wrote:
> >> Is there any reason why the setting synchronize_seqscans is in the
> >> section "version/platform compatibilit
On Tue, Dec 20, 2011 at 14:47, k...@rice.edu wrote:
> On Tue, Dec 20, 2011 at 02:41:54PM +0100, Magnus Hagander wrote:
>> On Tue, Dec 20, 2011 at 14:38, Robert Haas wrote:
>> > On Tue, Dec 20, 2011 at 8:35 AM, Magnus Hagander
>> > wrote:
>> >> Is there any reason why the setting synchronize_seq
On Tue, Dec 20, 2011 at 02:54:32PM +0100, Magnus Hagander wrote:
> On Tue, Dec 20, 2011 at 14:47, k...@rice.edu wrote:
> > On Tue, Dec 20, 2011 at 02:41:54PM +0100, Magnus Hagander wrote:
> >> On Tue, Dec 20, 2011 at 14:38, Robert Haas wrote:
> >> > On Tue, Dec 20, 2011 at 8:35 AM, Magnus Hagande
> > Agreed. I just tried out the scenarios laid out by you both with and
> without
> > the committed patch and AFAICS, normal inheritance semantics have been
> > preserved properly even after the commit.
>
> No, they haven't. I didn't expect this to break anything when you
> have two constraints w
Hi,
I've sent a first patch to improve extensions for 9.2, and intend on
sending a few more which I'll briefly present here. The point of this
email is to figure out how to branch the development, as all the patch
are going to conflict somehow (change the same parts of the code).
Either I develop
> rhaas=# create table A(ff1 int);
>> CREATE TABLE
>> rhaas=# create table B () inherits (A);
>> CREATE TABLE
>> rhaas=# create table C () inherits (B);
>> CREATE TABLE
>> rhaas=# alter table only b add constraint chk check (ff1 > 0);
>> ALTER TABLE
>> rhaas=# alter table a add constraint chk check
"k...@rice.edu" writes:
> On Tue, Dec 20, 2011 at 02:54:32PM +0100, Magnus Hagander wrote:
>>> Seems very different to me - those change *what* happens when you do
>>> certain things. sync_seqscans is just a performance tuning option, no?
>>> It doesn't actually change the semantics of any operati
On 20 December 2011 13:38, Magnus Hagander wrote:
> from postgresql.conf.sample:
>
> #replication_timeout = 60s # in milliseconds; 0 disables
>
> Seconds or milliseconds? I would suggest we just remove the "in
> milliseconds", and instead say "timeout for replication connections; 0
> disables
On Tue, Dec 20, 2011 at 07:08, Tom Lane wrote:
> it'd likely be better if this code ignored unrecognized qual expression
> types rather than Assert'ing they're not there.
The patch replaced that Assert with an elog(ERROR)
> Hmm. I am reminded of how utterly unreadable "diff -u" format is for
>
On Mon, Dec 19, 2011 at 11:13:57PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > I created a function that does this in a loop:
>
> > HeapTuple t;
>
> > CatalogCacheFlushCatalog(ProcedureRelationId);
> > t = SearchSysCache1(PROCOID, ObjectIdGetDatum(42) /* i
Noah Misch writes:
> On Mon, Dec 19, 2011 at 11:13:57PM -0500, Tom Lane wrote:
>> ... but this performance test seems to me to be entirely misguided,
>> because it's testing a situation that isn't going to occur much in the
>> field, precisely because the syscache should prevent constant reloads o
On Tue, Dec 20, 2011 at 8:36 AM, Robert Haas wrote:
> On Mon, Dec 19, 2011 at 2:44 PM, Kevin Grittner
> wrote:
>> I was thinking that we would warn when such was found, set hint bits
>> as needed, and rewrite with the new CRC. In the unlikely event that
>> it was a torn hint-bit-only page update
On Tue, Dec 20, 2011 at 1:40 PM, Magnus Hagander wrote:
> These days we have pause_at_recovery_target, which lets us pause when
> we reach a PITR target. Is there a particular reason we don't have a
> way to pause at end of recovery if we *didn't* specify a target -
> meaning we let it run until t
Excerpts from Christopher Browne's message of mar dic 20 14:12:56 -0300 2011:
> It's not evident which problems will be "real" ones. And in such
> cases, is the answer to turf the database and recover from backup,
> because of a single busted page? For a big database, I'm not sure
> that's less
Peter Geoghegan wrote:
> Magnus Hagander wrote:
>> from postgresql.conf.sample:
>>
>> #replication_timeout = 60s # in milliseconds; 0 disables
>>
>> Seconds or milliseconds? I would suggest we just remove the "in
>> milliseconds", and instead say "timeout for replication
>> connections; 0 di
Robert Haas wrote:
> On Mon, Dec 19, 2011 at 2:44 PM, Kevin Grittner
> wrote:
>> I was thinking that we would warn when such was found, set hint
>> bits as needed, and rewrite with the new CRC. In the unlikely
>> event that it was a torn hint-bit-only page update, it would be a
>> warning about
Alvaro Herrera wrote:
> Excerpts from Christopher Browne's message of mar dic 20 14:12:56
> -0300 2011:
>
>> It's not evident which problems will be "real" ones. And in such
>> cases, is the answer to turf the database and recover from
>> backup, because of a single busted page? For a big datab
On Tuesday, December 20, 2011 06:38:44 PM Kevin Grittner wrote:
> Alvaro Herrera wrote:
> > Excerpts from Christopher Browne's message of mar dic 20 14:12:56
> >
> > -0300 2011:
> >> It's not evident which problems will be "real" ones. And in such
> >> cases, is the answer to turf the database a
On Tue, Dec 20, 2011 at 12:38 PM, Kevin Grittner
wrote:
>> I don't think the problem is having one page of corruption. The
>> problem is *not knowing* that random pages are corrupted, and
>> living in the fear that they might be.
>
> What would you want the server to do when a page with a mismat
Andres Freund writes:
> On Tuesday, December 20, 2011 06:38:44 PM Kevin Grittner wrote:
>> What would you want the server to do when a page with a mismatching
>> checksum is read?
> Follow the behaviour of zero_damaged_pages.
Surely not. Nobody runs with zero_damaged_pages turned on in
producti
On Tuesday, December 20, 2011 07:08:56 PM Tom Lane wrote:
> Andres Freund writes:
> > On Tuesday, December 20, 2011 06:38:44 PM Kevin Grittner wrote:
> >> What would you want the server to do when a page with a mismatching
> >> checksum is read?
> >
> > Follow the behaviour of zero_damaged_pages.
On Mon, Dec 19, 2011 at 11:10 AM, Simon Riggs wrote:
> The only sensible way to handle this is to change the page format as
> discussed. IMHO the only sensible way that can happen is if we also
> support an online upgrade feature. I will take on the online upgrade
> feature if others work on the
"David E. Wheeler" writes:
> holds: it is not a programming language, and one does not need a PL to have
> a JSON data type.
Exactly. That does not contradict the fact that if you have
pl/ecmascript you already have JSON. And that we might as well have had
the ecmascript PL for some time now, w
On Tuesday, December 20, 2011 06:44:48 PM Simon Riggs wrote:
> Currently, setting hints can be done while holding a share lock on the
> buffer. Preventing that would require us to change the way buffer
> manager works to make it take an exclusive lock while writing out,
> since a hint would change
On Tuesday, December 20, 2011 07:23:43 PM Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
> > holds: it is not a programming language, and one does not need a PL to
> > have a JSON data type.
> Exactly. That does not contradict the fact that if you have
> pl/ecmascript you already have JSON.
On Dec 20, 2011, at 12:39 AM, David E. Wheeler wrote:
> On Dec 19, 2011, at 2:49 AM, Dimitri Fontaine wrote:
>
>> My understanding is that JSON is a subset of ECMAscript
>
> Well, no, JSON is formally “a lightweight data-interchange format.” It’s
> derived from JavaScript syntax, but it is not a
On 2011-12-20 18:44, Simon Riggs wrote:
On Mon, Dec 19, 2011 at 11:10 AM, Simon Riggs wrote:
The only sensible way to handle this is to change the page format as
discussed. IMHO the only sensible way that can happen is if we also
support an online upgrade feature. I will take on the online upg
On 2011-12-19 02:55, Greg Stark wrote:
On Sun, Dec 18, 2011 at 7:51 PM, Jesper Krogh wrote:
I dont know if it would be seen as a "half baked feature".. or similar,
and I dont know if the hint bit problem is solvable at all, but I could
easily imagine checksumming just "skipping" the hit bit ent
On 20.12.2011 11:20, Magnus Hagander wrote:
> 2011/12/20 Tomas Vondra :
>>
>> I haven't updated the docs yet - let's see if the patch is acceptable at
>> all first.
>
> Again, without having reviewed the code, this looks like a feature
> we'd want, so please add some docs, and then submit it for t
In a discussion on irc today, someone had a need to confirm that a
business rule (this table has two rows for every related one row in
another table) was true at commit time. I innocently suggested a
deferrable (and deferred) trigger. It was pointed out that the
docs:
http://www.postgresql.org/
On Mon, Dec 19, 2011 at 5:49 AM, Dimitri Fontaine
wrote:
> My understanding is that JSON is a subset of ECMAscript, so if you get
> the latter you already have the former. Now, someone would have to
> check if plscheme still build with guile-2.0, and given that, how
> exactly you get pl/ecmascrip
"Kevin Grittner" writes:
> In a discussion on irc today, someone had a need to confirm that a
> business rule (this table has two rows for every related one row in
> another table) was true at commit time. I innocently suggested a
> deferrable (and deferred) trigger. It was pointed out that the
Alvaro Herrera writes:
> I've been trying to implement the holy grail of decoupling
> logical/physical column sort order representation, i.e., the feature
> that lets the server have one physical order, for storage compactness,
> and a different "output" order that can be tweaked by the user. Thi
Excerpts from Tom Lane's message of mar dic 20 18:24:29 -0300 2011:
> Alvaro Herrera writes:
> > I've been trying to implement the holy grail of decoupling
> > logical/physical column sort order representation, i.e., the feature
> > that lets the server have one physical order, for storage compac
Tom Lane wrote:
> "Kevin Grittner" writes:
>> In a discussion on irc today, someone had a need to confirm that
>> a business rule (this table has two rows for every related one
>> row in another table) was true at commit time. I innocently
>> suggested a deferrable (and deferred) trigger. It wa
"Kevin Grittner" writes:
> Tom Lane wrote:
>> What do you mean by "hand-written DEFERRABLE trigger"?
> Ah, I had forgotten that I had to use the CONSTRAINT keyword in the
> trigger definition; the sentence in the docs makes more sense now.
> I wrote a plpgsql trigger function and created a de
Marti Raudsepp writes:
> On Tue, Dec 20, 2011 at 07:08, Tom Lane wrote:
>> but I think I don't
>> like this refactoring much. Will take a closer look tomorrow.
> I was afraid you'd say that, especially for a change that should be
> backpatched. But I couldn't think of alternative ways to do it
On Mon, Dec 19, 2011 at 11:52:54PM -0500, Robert Haas wrote:
> After staring at this for quite a while longer, it seemed to me that
> the logic for renaming a relation was similar enough to the logic for
> changing a schema that the two calbacks could reasonably be combined
> using a bit of conditi
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mar dic 20 18:24:29 -0300 2011:
>> You do *not* want to store either of the latter two numbers in
>> parse-time Var nodes, because then you can't rearrange columns without
>> having to update stored rules. But it might be useful to decr
On Dec 19, 2011, at 9:00 PM, Robert Haas wrote:
>> +1, though I think the core type will at least need some basic operators and
>> indexing support.
>
> And I'm willing to do that, but I thought it best to submit a bare
> bones patch first, in the hopes of minimizing the number of
> objectionabl
On Dec 20, 2011, at 2:13 AM, Magnus Hagander wrote:
> Yes, that's why I said "few" not "none".
>
> Though in my experience, most companies are a lot more restrictive
> about addons to their database than addons to their development
> environments.
Yeah, we’re getting off-topic here, so I’ll just
On Dec 20, 2011, at 10:39 AM, Claes Jakobsson wrote:
> Are people explicitly asking for a) *JSON* datatype or b) a type that lets
> you store arbitrary complex semi-untyped data structures?
Yes.
> if b) then this might get a lot more interesting
JSON is the most popular/likely way to represent
Thanks for you reply.
I found query without cursor is faster then query with server-side cursor
and several fetches.
But I have a large result set to retrieve from database. I have to choose
server-side cursor
to avoid out-of-memory problem.
When I try to debug the cursor and fetch, I found this
A few weeks ago I posted some performance results showing that
increasing NUM_CLOG_BUFFERS was improving pgbench performance.
http://archives.postgresql.org/pgsql-hackers/2011-12/msg00095.php
I spent some time today looking at this in a bit more detail.
Somewhat obviously in retrospect, it turns
=?UTF-8?B?6auY5aKe55Cm?= writes:
> Here is the example:
> create table t (a int);
> insert into t values (1),(3),(5),(7),(9);
> insert into t select a+1 from t;
> begin;
> declare c cursor for select * from t order by a;
> fetch 3 in c;
> fetch 3 in c;
> fetch 3 in c;
>
> In 'PortalRun', a fetch
Robert Haas writes:
> So, what do we do about this? The obvious answer is "increase
> NUM_CLOG_BUFFERS", and I'm not sure that's a bad idea.
As you say, that's likely to hurt people running in small shared
memory. I too have thought about merging the SLRU areas into the main
shared buffer arena
Robert Haas writes:
> ... while the main buffer manager is
> content with some loosey-goosey approximation of recency, the SLRU
> code makes a fervent attempt at strict LRU (slightly compromised for
> the sake of reduced locking in SimpleLruReadPage_Readonly).
Oh btw, I haven't looked at that cod
On 12/19/2011 06:14 PM, Kevin Grittner wrote:
But if you need all that infrastructure just to get the feature
launched, that's a bit hard to stomach.
Triggering a vacuum or some hypothetical "scrubbing" feature?
What you were suggesting doesn't require triggering just a vacuum
tho
68 matches
Mail list logo
