于 2013-09-06 01:41, Jeff Janes 回复:
On Wed, Sep 4, 2013 at 10:06 PM, wrote:
于 2013-09-04 23:41, Jeff Janes 回复:
On Tue, Sep 3, 2013 at 9:08 PM, wrote:
Hi, Hackers!
I find that it takes a long time when I increase the scale of a
numeric
datatype.
By checking the code, I found that's beca
Bruce Momjian escribió:
> Ideas
> -
>
> I think we need to detect tables that do not have VM bits set and try to
> determine if they should be vacuumed. If a table has most of its VM
> bits set, there in need to vacuum it for VM bit setting.
I think it's shortsighted to keep thinking of aut
On 09/05/2013 03:30 PM, Merlin Moncure wrote:
>> Standard advice we've given in the past is 25% shared buffers, 75%
>> effective_cache_size. Which would make EFS *3X* shared_buffers, not 4X.
>> Maybe we're changing the conventional calculation, but I thought I'd
>> point that out.
>
> This was
On Thu, Sep 05, 2013 at 10:41:25AM -0700, Jeff Janes wrote:
> In order to avoid the rewrite, the code would have to be changed to
> look up the column definition and if it specifies the scale, then
> ignore the per-row n_header, and look at the n_header only if the
> column is NUMERIC with no preci
On Thu, Sep 5, 2013 at 09:10:06PM -0400, Robert Haas wrote:
> On Thu, Sep 5, 2013 at 8:14 PM, Bruce Momjian wrote:
> > Actually, I now realize it is more complex than that, and worse. There
> > are several questions to study to understand when pg_class.relallvisible
> > is updated (which is used
On 06/09/13 13:10, Robert Haas wrote:
On Thu, Sep 5, 2013 at 8:14 PM, Bruce Momjian wrote:
Actually, I now realize it is more complex than that, and worse. There
are several questions to study to understand when pg_class.relallvisible
is updated (which is used to determine if index-only scans
On Tue, Aug 27, 2013 at 1:14 PM, Heikki Linnakangas
wrote:
> Assuming no objections, I'll apply the attached patch to 9.3 and master
> later tonight.
Just a little stylistic nitpick: could we pluralize the --help outputs
for the modified options so that they make clear that multiple
specification
On Thu, Sep 5, 2013 at 8:14 PM, Bruce Momjian wrote:
> Actually, I now realize it is more complex than that, and worse. There
> are several questions to study to understand when pg_class.relallvisible
> is updated (which is used to determine if index-only scans are a good
> optimization choice),
On Wed, Sep 4, 2013 at 04:56:55PM -0400, Bruce Momjian wrote:
> > "Add a column pg_class.relallvisible to remember the number of pages
> > that were all-visible according to the visibility map as of the last
> > VACUUM
> > (or ANALYZE, or some other operations that update pg_class.relpages).
> > U
On Thu, Sep 5, 2013 at 03:11:53PM -0700, Josh Berkus wrote:
> On 09/05/2013 02:16 PM, Bruce Momjian wrote:
> >> Well, the real problem with this patch is that it documents what the
> >> auto-tuning algorithm is; without that commitment, just saying "-1 means
> >> autotune" might be fine.
> >
> >
On Thu, Sep 5, 2013 at 5:11 PM, Josh Berkus wrote:
> On 09/05/2013 02:16 PM, Bruce Momjian wrote:
>>> Well, the real problem with this patch is that it documents what the
>>> auto-tuning algorithm is; without that commitment, just saying "-1 means
>>> autotune" might be fine.
>>
>> OK, but I did t
Never mind I think I found it.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Where-can-I-find-the-code-for-extern-OidFunctionCall7-tp5769737p5769801.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (
The comments on this sourcebase are really good, plus it is very well
structured!
I read somewhere that you can actually "store" an execution plan by using
stored procedures. If that is the case. I would imagine that variables would
prevent the histograms from being used. I don't mind finding the
On 09/05/2013 02:16 PM, Bruce Momjian wrote:
>> Well, the real problem with this patch is that it documents what the
>> auto-tuning algorithm is; without that commitment, just saying "-1 means
>> autotune" might be fine.
>
> OK, but I did this based on wal_buffers, which has a -1 default, calls
>
On Mon, Aug 19, 2013 at 09:27:57PM -0400, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > I vote for adapting the patch to additionally zero out the file via
> > write(). In your tests that seemed to perform at least as good as the
> > old method... It also has the advant
On Thu, Sep 5, 2013 at 12:48:54PM -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Sep 5, 2013 at 3:01 AM, Bruce Momjian wrote:
> >> I have developed the attached patch which implements an auto-tuned
> >> effective_cache_size which is 4x the size of shared buffers. I had to
> >> set
On 2013-02-26 13:08:54 +0100, Andres Freund wrote:
> Just for reference, thats the grammar for SET/SHOW:
>
> var_name: ColId
> { $$ = $1; }
> | var_name '.' ColId
>
> Any arguments whether we should try to validate
On Thu, Sep 5, 2013 at 06:14:33PM +0200, Magnus Hagander wrote:
> > I have developed the attached patch which implements an auto-tuned
> > effective_cache_size which is 4x the size of shared buffers. I had to
> > set effective_cache_size to its old 128MB default so the EXPLAIN
> > regression test
On Thu, Sep 5, 2013 at 02:14:39PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Sep 4, 2013 at 9:26 PM, Bruce Momjian wrote:
> >> I have not heard any feedback on this patch, so I would like to apply it
> >> to give us a nested ROW/IS NULL API we can document. It would have to
> >> b
Greg Stark escribió:
> The main difficulty is that Postgres is very extensible. So to implement
> this you need to think bigger than NUMERIC. It should also be possible to
> alter a column from varchar(5) to varchar(10) for example (but not the
> other way around).
We already allow that. See com
Kevin Grittner wrote:
> New patch attached.
Pushed (to master only).
277607d600fb71e25082b94302ca1716403cd0bc
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
On Thu, Sep 5, 2013 at 6:41 PM, Jeff Janes wrote:
> Then if the column was
> altered from NUMERIC with scale to be a plain NUMERIC, it would have
> to rewrite the table to enforce the row-wise scale to match the old
> column-wise scale. Where as now that alter doesn't need a re-write.
> I don't
On 2013-09-05 14:37:01 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-09-05 14:21:33 -0400, Tom Lane wrote:
> >> Ideally I'd have made InvalidCommandId = 0 and FirstCommandId = 1,
> >> but I suppose we can't have that without an on-disk compatibility break.
>
> > The patch actually do
On 2013-09-05 21:02:44 +0200, Andres Freund wrote:
> On 2013-09-05 14:37:01 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2013-09-05 14:21:33 -0400, Tom Lane wrote:
> > >> Ideally I'd have made InvalidCommandId = 0 and FirstCommandId = 1,
> > >> but I suppose we can't have that without
On Thu, Sep 5, 2013 at 11:30 AM, Andres Freund wrote:
>> Ideally I'd have made InvalidCommandId = 0 and FirstCommandId = 1,
>> but I suppose we can't have that without an on-disk compatibility break.
>
> The patch actually does change it exactly that way. My argument for that
> being valid is that
Hi Peter,
Thanks for checking the tests. I wasn't able to duplicate your test
results. Did you run the hstore regression tests with the revised patch I
attached in the thread? Attached is the output I got with the latest patch
applied.
Thanks!
Blake
On Tue, Sep 3, 2013 at 8:04 PM, Peter Eise
Hi,
Heikki's catcache rehashing stuff reminded me that I'd posted an
optimization to catcache (20121220153555.gh4...@awork2.anarazel.de) some
time back which I didn't have energy to pursue at that point.
I've brushed the patch up a bit and verified it still gives be a
performance improvement. It'
Andres Freund writes:
> On 2013-09-05 14:21:33 -0400, Tom Lane wrote:
>> Ideally I'd have made InvalidCommandId = 0 and FirstCommandId = 1,
>> but I suppose we can't have that without an on-disk compatibility break.
> The patch actually does change it exactly that way.
Oh. I hadn't looked at th
Hi,
Thanks for weighin in.
On 2013-09-05 14:21:33 -0400, Tom Lane wrote:
> Robert Haas writes:
> > OK. Consider me more of a -0 than a -1. Like I say, I don't really
> > want to block it; I just don't feel comfortable committing it unless a
> > few other people say something like "I don't see
Alvaro Herrera wrote:
> I was scrolling heapgettup() and heapgettup_pagemode() in parallel, and
> noticed that the former calls CheckForSerializableConflictOut() for
> tuples read, and the latter doesn't. Is there a reason for this
> discrepancy? If so, I think it warrants a comment about the m
Robert Haas writes:
> OK. Consider me more of a -0 than a -1. Like I say, I don't really
> want to block it; I just don't feel comfortable committing it unless a
> few other people say something like "I don't see a problem with that".
FWIW, I've always thought it was a wart that there wasn't a
Robert Haas writes:
> On Wed, Sep 4, 2013 at 9:26 PM, Bruce Momjian wrote:
>> I have not heard any feedback on this patch, so I would like to apply it
>> to give us a nested ROW/IS NULL API we can document. It would have to
>> be marked in the release notes as a backward incompatibility.
> I do
On 05.09.2013 20:30, Alvaro Herrera wrote:
I was scrolling heapgettup() and heapgettup_pagemode() in parallel, and
noticed that the former calls CheckForSerializableConflictOut() for
tuples read, and the latter doesn't. Is there a reason for this
discrepancy? If so, I think it warrants a commen
On Thu, Sep 5, 2013 at 12:38 PM, arthernan wrote:
> OidFunctionCall7 is called from costsize.c, in function void cost_index. From
> the comments, I understand that there is an indirection mechanism here to
> allow for different index access methods. Looking at fmgr.h where it is
> declared is not
On Wed, Sep 4, 2013 at 10:06 PM, wrote:
> 于 2013-09-04 23:41, Jeff Janes 回复:
>
>> On Tue, Sep 3, 2013 at 9:08 PM, wrote:
>>>
>>> Hi, Hackers!
>>>
>>> I find that it takes a long time when I increase the scale of a numeric
>>> datatype.
>>> By checking the code, I found that's because it needs t
On Thu, Sep 5, 2013 at 12:59 PM, Andres Freund wrote:
> On 2013-09-05 12:44:18 -0400, Robert Haas wrote:
>> On Wed, Sep 4, 2013 at 12:07 PM, Andres Freund
>> wrote:
>> > On 2013-09-03 11:40:57 -0400, Robert Haas wrote:
>> >> > 0002 wal_decoding: Introduce InvalidCommandId and declare that to be
Hi Kevin,
On 2013-09-03 11:40:57 -0400, Robert Haas wrote:
> On Fri, Aug 30, 2013 at 11:19 AM, Andres Freund
> wrote:
> > 0007 wal_decoding: Add information about a tables primary key to struct
> > RelationData
> > * Could be used in the matview refresh code
> I think you and Kevin should disc
I was scrolling heapgettup() and heapgettup_pagemode() in parallel, and
noticed that the former calls CheckForSerializableConflictOut() for
tuples read, and the latter doesn't. Is there a reason for this
discrepancy? If so, I think it warrants a comment about the missing
check.
Thanks,
--
Álva
On 09/05/2013 09:42 AM, Josh Berkus wrote:
Peter,
Other ideas? Are there legitimate uses for SQL_ASCII?
Migrating from MySQL. We've had some projects where we couldn't fix
MySQL's non-enforcement text garbage, and had to use SQL_ASCII on the
receiving side. If it hadn't been available, t
On 05.09.2013 17:22, Tom Lane wrote:
Heikki Linnakangas writes:
I ran pgbench for ten seconds, and printed the number of tuples in each
catcache after that:
[ very tiny numbers ]
I find these numbers a bit suspicious. For example, we must have hit at
least 13 different system catalogs, and m
Thank you guys!
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Where-can-I-find-the-code-for-extern-OidFunctionCall7-tp5769737p5769753.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
OidFunctionCall7 is called from costsize.c, in function void cost_index. From
the comments, I understand that there is an indirection mechanism here to
allow for different index access methods. Looking at fmgr.h where it is
declared is not clear to me where I would ultimately find the code.
Any po
On Thu, Sep 05, 2013 at 09:53:18AM -0700, Joshua D. Drake wrote:
>
> On 09/05/2013 09:42 AM, Josh Berkus wrote:
> >
> >Peter,
> >
> >>Other ideas? Are there legitimate uses for SQL_ASCII?
> >
> >Migrating from MySQL. We've had some projects where we couldn't fix
> >MySQL's non-enforcement text g
On 09/05/2013 10:02 AM, Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>> iconv?
>
> Command Prompt helped a customer normalize encodings in their data,
> which was a mixture of Latin1 and UTF8. PGLoader was used for this, in
> two stages; the first run in UTF8 saved the rejected data to a file
>
On Thu, Sep 05, 2013 at 09:42:17AM -0700, Josh Berkus wrote:
> Peter,
>
> > Other ideas? Are there legitimate uses for SQL_ASCII?
>
> Migrating from MySQL. We've had some projects where we couldn't fix
> MySQL's non-enforcement text garbage, and had to use SQL_ASCII on the
> receiving side. If
Hi,
On 2013-09-03 11:40:57 -0400, Robert Haas wrote:
> On Fri, Aug 30, 2013 at 11:19 AM, Andres Freund
> wrote:
> > 0005 wal_decoding: Log xl_running_xact's at a higher frequency than
> > checkpoints are done
> > * benefits hot standby startup
I tried to update the patch to address the comment
Peter,
> Other ideas? Are there legitimate uses for SQL_ASCII?
Migrating from MySQL. We've had some projects where we couldn't fix
MySQL's non-enforcement text garbage, and had to use SQL_ASCII on the
receiving side. If it hadn't been available, the user would have given
up on Postgres.
--
J
On Wed, Sep 4, 2013 at 12:07 PM, Andres Freund wrote:
> On 2013-09-03 11:40:57 -0400, Robert Haas wrote:
>> > 0002 wal_decoding: Introduce InvalidCommandId and declare that to be the
>> > new maximum for CommandCounterIncrement
>>
>> I'm still unconvinced we want this.
>
> Ok, so the reason for t
On 2013-09-05 12:44:18 -0400, Robert Haas wrote:
> On Wed, Sep 4, 2013 at 12:07 PM, Andres Freund wrote:
> > On 2013-09-03 11:40:57 -0400, Robert Haas wrote:
> >> > 0002 wal_decoding: Introduce InvalidCommandId and declare that to be the
> >> > new maximum for CommandCounterIncrement
> >>
> >> I'
On Thu, Sep 5, 2013 at 3:01 AM, Bruce Momjian wrote:
> On Tue, Jan 8, 2013 at 08:40:44PM -0500, Andrew Dunstan wrote:
>>
>> On 01/08/2013 08:08 PM, Tom Lane wrote:
>> >Robert Haas writes:
>> >>On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane wrote:
>> >>>... And I don't especially like the idea of try
On Wed, Sep 4, 2013 at 9:26 PM, Bruce Momjian wrote:
> On Tue, Sep 3, 2013 at 09:32:44PM -0400, Bruce Momjian wrote:
>> In this test, SELECT NULL (which internally would produce SELECT
>> ROW(NULL)), returns TRUE, while SELECT ROW(NULL) and further nesting
>> returns false.
>>
>> This has made me
On Wed, Sep 4, 2013 at 11:02 PM, Quan Zongliang wrote:
> I think of a new idea.
> Add a compare method column to pg_collation.
> Every collation has its own compare function or null.
> When function varstr_cmp is called, if specified collation
> has compare function, call it instead of strcoll().
On Wed, Sep 4, 2013 at 6:38 PM, Jim Nasby wrote:
>> No, I meant something that would live as long as the postmaster and
>> die when it dies.
>
> ISTM that at some point we'll want to look at putting top-level shared
> memory into this system (ie: allowing dynamic resizing of GUCs that affect
> sha
On Wed, Sep 4, 2013 at 8:08 PM, Andres Freund wrote:
> You've proposed an framework and algorithm for something I'd really, really
> like to see. I don't think that it can work explicitly as you proposed, so I
> roughly sketched out a solution I can see.
> I don't want "my" idea to win, I want a
Magnus Hagander writes:
> On Thu, Sep 5, 2013 at 3:01 AM, Bruce Momjian wrote:
>> I have developed the attached patch which implements an auto-tuned
>> effective_cache_size which is 4x the size of shared buffers. I had to
>> set effective_cache_size to its old 128MB default so the EXPLAIN
>> reg
arthernan wrote:
> OidFunctionCall7 is called from costsize.c, in function void cost_index. From
> the comments, I understand that there is an indirection mechanism here to
> allow for different index access methods. Looking at fmgr.h where it is
> declared is not clear to me where I would ultimate
Joshua D. Drake wrote:
>
> On 09/05/2013 09:42 AM, Josh Berkus wrote:
> >>Other ideas? Are there legitimate uses for SQL_ASCII?
> >
> >Migrating from MySQL. We've had some projects where we couldn't fix
> >MySQL's non-enforcement text garbage, and had to use SQL_ASCII on the
> >receiving side.
Heikki Linnakangas writes:
> I ran pgbench for ten seconds, and printed the number of tuples in each
> catcache after that:
> [ very tiny numbers ]
I find these numbers a bit suspicious. For example, we must have hit at
least 13 different system catalogs, and more than that many indexes, in
the
On Wed, Aug 28, 2013 at 12:09:05AM -0400, Peter Eisentraut wrote:
> On Tue, 2013-08-27 at 09:44 -0400, Tom Lane wrote:
> > Boszormenyi Zoltan writes:
> > > When adding regression tests, can you please add intentional
> > > syntax error cases to exercise all the new ereport()s?
> >
> > Please do n
On 2013-08-09 14:14:34, Craig Ringer wrote:
>Well, if you're planning on relying on libxml in core (and it'll have to
>be in core if you're adding new syntax) then you'll need a solid, well
>researched answer to that one or an alternative XML library that's
>portable and doesn't have those iss
On Thu, Sep 05, 2013 at 08:47:32AM -0400, Peter Eisentraut wrote:
> Can we consider getting rid of the SQL_ASCII server-side "encoding"? I
> don't see any good use for it, and it's often a support annoyance, and
> it leaves warts all over the code. This would presumably be a
> multi-release effor
On 05.09.2013 15:47, Peter Eisentraut wrote:
Can we consider getting rid of the SQL_ASCII server-side "encoding"? I
don't see any good use for it, and it's often a support annoyance, and
it leaves warts all over the code. This would presumably be a
multi-release effort.
I think "warts all ove
On Thu, Sep 5, 2013 at 7:47 AM, Peter Eisentraut wrote:
> Can we consider getting rid of the SQL_ASCII server-side "encoding"? I
> don't see any good use for it, and it's often a support annoyance, and
> it leaves warts all over the code. This would presumably be a
> multi-release effort.
>
> As
Can we consider getting rid of the SQL_ASCII server-side "encoding"? I
don't see any good use for it, and it's often a support annoyance, and
it leaves warts all over the code. This would presumably be a
multi-release effort.
As a first step in accommodating users who have existing SQL_ASCII
dat
On Thu, Sep 05, 2013 at 11:07:43AM +0800, wangs...@highgo.com.cn wrote:
> ??? 2013-09-04 19:30, Noah Misch ??:
>> On Wed, Sep 04, 2013 at 12:08:48PM +0800, wangs...@highgo.com.cn
>> wrote:
>>> I find that it takes a long time when I increase the scale of a
>>> numeric
>>> datatype.
>>> By c
On 04.09.2013 23:56, Tom Lane wrote:
Heikki Linnakangas writes:
One fairly simple thing we could do is to teach catcache.c to resize the
caches. Then we could make the initial size of all the syscaches much
smaller.
I think this is attractive for the *other* reason you mention, namely
preserv
Hello All,
I am trying to revive the discussion about exposing queryid in
pg_stat_statements.
I did find the same request posted on hackers @
http://www.postgresql.org/message-id/CABUevExLnb6xJwS=8rTaLOfDOS-tFm09==z2m_vz5hhfkgw...@mail.gmail.com
and
http://www.postgresql.org/message-id/cacn56+n
(2013/09/05 0:04), Andres Freund wrote:
> I'd vote for adding zeroing *after* the fallocate() first.
+1, with FALLOC_FL_KEEP_SIZE flag.
At least, fallocate with FALLOC_FL_KEEP_SIZE flag is faster than nothing in my
developing sorted checkpoint. I adopted it to relation file, so I don't know
abo
On Thu, Sep 5, 2013 at 10:59 AM, Alvaro Herrera
wrote:
> Satoshi Nagayasu wrote:
>
>> But, for now, I think we should have a real index for the
>> statistics data because we already have several index storages,
>> and it will allow us to minimize read/write operations.
>>
>> BTW, what kind of inde
69 matches
Mail list logo
