Alvaro Herrera wrote:
I wonder if we could instead make vacuum write a new FSM tree from
scratch, rather than updating it piecemeal.
I'd like to move away from that, as we'll hopefully get some sort of
partial vacuum capability soon.
We might want to have some sort of bulk update operation,
On Fri, Jul 4, 2008 at 5:20 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> * If the patch was implemented as an ExplainOneQuery_hook we would be
> able to use this with 8.3 also, which might be interesting. So there's
> no real need for this to be a patch on core.
Would that mean that instead of b
Heikki Linnakangas wrote:
> Simon Riggs wrote:
>> What if we bubbled up based
>> upon only significant tree changes, rather than exact changes?
>
> Hmm. So an update would only ever update the lowest-level FSM page, and
> leave a mismatch between the value at the root node of a lower level FSM
On Fri, 2008-07-04 at 12:05 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Anyway, I note that we don't have an easy way of sorting by tablespace,
>
> Say what? tablespace is the first component of relfilenode.
OK, thats a mistake... what about the rest of the idea?
--
On Tue, 2008-07-01 at 21:48 -0700, Tom Raney wrote:
> This is an update to my EXPLAIN XML patch submitted a few days ago.
This is an important patch and you've done well to get it this far.
I have much detailed feedback, but these are just emergent requests, now
I can see and understand what you
Simon Riggs <[EMAIL PROTECTED]> writes:
> Anyway, I note that we don't have an easy way of sorting by tablespace,
Say what? tablespace is the first component of relfilenode.
> but I'm sure it would be possible to look up the tablespace for a file
> within a plugin.
If the information weren't re
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 4. Juli 2008 schrieb Tom Raney:
>> Regarding the XML datum, in order to support that, will all users need
>> to compile with libxml? Are there any lighter weight solutions to
>> serialize other than libxml?
> You can create XML withou
On Fri, 2008-07-04 at 15:20 +0300, Heikki Linnakangas wrote:
> 2. We only update the FSM when we try to insert a tuple and find that it
> doesn't fit. That reduces the amount of FSM updates dramatically when
> you're doing bulk inserts. (This is the same as in the current
> implementation, tho
Simon Riggs wrote:
On Fri, 2008-07-04 at 12:27 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Fri, 2008-06-27 at 19:36 +0300, Heikki Linnakangas wrote:
Here's an updated version of the "relation forks" patch, and an
incremental FSM rewrite patch on top of that. The relation forks patc
Pavan Deolasee napsal(a):
On Fri, Jul 4, 2008 at 4:25 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
No, there's a itemsz = MAXALIGN(itemsz) call before the check against
HashMaxItemSize.
Ah, right. Still should we just not MAXALIGN_DOWN the Max size to
reflect the practical limit on the
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
By my opinion first place where tuple should be placed is:
MAXALIGN(SizeOfPageHeaderData + sizeof(ItemIdData))
Yeah, but we don't enforce that directly. We enforce it by MAXALIGNing
size in PageAddItem, and with the rule that special-size is
Zdenek Kotala wrote:
By my opinion first place where tuple should be placed is:
MAXALIGN(SizeOfPageHeaderData + sizeof(ItemIdData))
Yeah, but we don't enforce that directly. We enforce it by MAXALIGNing
size in PageAddItem, and with the rule that special-size is MAXALIGNed.
To put it anothe
Pavan Deolasee napsal(a):
On Fri, Jul 4, 2008 at 4:20 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
By my opinion first place where tuple should be placed is:
MAXALIGN(SizeOfPageHeaderData + sizeof(ItemIdData))
Tuple actually starts from the other end of the block.
Yes, but I meant first
Heikki Linnakangas napsal(a):
Pavan Deolasee wrote:
On Fri, Jul 4, 2008 at 3:37 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
I think this is the way it should be:
#define HashMaxItemSize \
(BLCKSZ - \
SizeOfPageHeaderData - \
MAXALIGN(sizeof(HashPageOpaqueData)) -
On Fri, 2008-07-04 at 12:27 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2008-06-27 at 19:36 +0300, Heikki Linnakangas wrote:
> >
> >> Here's an updated version of the "relation forks" patch, and an
> >> incremental FSM rewrite patch on top of that. The relation forks patch
On Fri, Jul 4, 2008 at 4:20 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
>
>
>
> By my opinion first place where tuple should be placed is:
>
> MAXALIGN(SizeOfPageHeaderData + sizeof(ItemIdData))
>
Tuple actually starts from the other end of the block.
Thanks,
Pavan
--
Pavan Deolasee
Enterprise
On Fri, Jul 4, 2008 at 4:25 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
>
>
> No, there's a itemsz = MAXALIGN(itemsz) call before the check against
> HashMaxItemSize.
>
Ah, right. Still should we just not MAXALIGN_DOWN the Max size to
reflect the practical limit on the itemsz ? It's more aca
Pavan Deolasee wrote:
On Fri, Jul 4, 2008 at 3:37 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
I think this is the way it should be:
#define HashMaxItemSize \
(BLCKSZ - \
SizeOfPageHeaderData - \
MAXALIGN(sizeof(HashPageOpaqueData)) - \
sizeof(ItemIdData))
Heikki Linnakangas napsal(a):
Pavan Deolasee wrote:
On Fri, Jul 4, 2008 at 1:01 PM, Zdenek Kotala <[EMAIL PROTECTED]>
wrote:
Good catch. I lost in basic arithmetic. What I see now that original
definition count sizeof(ItemIdData) twice and on other side it does
not take
care about MAXALING c
On Fri, Jul 4, 2008 at 3:37 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
>
>
> I think this is the way it should be:
>
> #define HashMaxItemSize \
>(BLCKSZ - \
> SizeOfPageHeaderData - \
> MAXALIGN(sizeof(HashPageOpaqueData)) - \
> sizeof(ItemIdData))
>
I am wo
Pavan Deolasee wrote:
On Fri, Jul 4, 2008 at 1:01 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
Good catch. I lost in basic arithmetic. What I see now that original
definition count sizeof(ItemIdData) twice and on other side it does not take
care about MAXALING correctly. I think correct formula
2008/7/4 Simon Riggs <[EMAIL PROTECTED]>:
>
> On Mon, 2008-06-23 at 15:13 +0200, Pavel Stehule wrote:
>
>> this patch enhance current syntax of CREATE FUNCTION statement. It
>> allows creating functions with variable number of arguments. This
>> version is different than last my patches. It doesn't
Pavan Deolasee napsal(a):
On Fri, Jul 4, 2008 at 2:08 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
Patch
modifies HashMaxItemSize. It should require reindex on all hash indexes.
Should we bump catalog version?
Do we really need that ? Even if the new HashMaxItemSize comes out to
be lower tha
Simon Riggs wrote:
On Fri, 2008-06-27 at 19:36 +0300, Heikki Linnakangas wrote:
Here's an updated version of the "relation forks" patch, and an
incremental FSM rewrite patch on top of that. The relation forks patch
is ready for review. The FSM implementation is more work-in-progress
still, bu
On Fri, 4 Jul 2008, Teodor Sigaev wrote:
What's the benefit of a multi-column GIN index over multiple
single-column GIN indexes?
Page 12 from presentation on PgCon
(http://www.sigaev.ru/gin/fastinsert_and_multicolumn_GIN.pdf):
Multicolumn index vs. 2 single column indexes
Size:539 Mb
On Mon, 2008-05-05 at 00:23 -0400, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Sun, 4 May 2008, Tom Lane wrote:
> >> Well, I tried a pgbench test similar to that one --- on smaller hardware
> >> than was reported, so it was a bit smaller test case, but it should have
> >> giv
On Fri, 2008-06-27 at 19:36 +0300, Heikki Linnakangas wrote:
> Here's an updated version of the "relation forks" patch, and an
> incremental FSM rewrite patch on top of that. The relation forks patch
> is ready for review. The FSM implementation is more work-in-progress
> still, but I'd like t
On Mon, 2008-06-23 at 15:22 +0900, ITAGAKI Takahiro wrote:
> I'm working on light-weight SQL logging for PostgreSQL.
> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00601.php
>
> I divide the SQL logging feature into a core patch and an extension module.
> I hope only the patch is to be
On Mon, 2008-06-23 at 15:13 +0200, Pavel Stehule wrote:
> this patch enhance current syntax of CREATE FUNCTION statement. It
> allows creating functions with variable number of arguments. This
> version is different than last my patches. It doesn't need patching
> PL. Basic idea is transformation
On Fri, Jul 4, 2008 at 2:08 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
> Patch
> modifies HashMaxItemSize. It should require reindex on all hash indexes.
> Should we bump catalog version?
>
Do we really need that ? Even if the new HashMaxItemSize comes out to
be lower than the current limit (be
Am Freitag, 4. Juli 2008 schrieb Tom Raney:
> Regarding the XML datum, in order to support that, will all users need
> to compile with libxml? Are there any lighter weight solutions to
> serialize other than libxml?
You can create XML without libxml.
--
Sent via pgsql-patches mailing list (
On Fri, Jul 4, 2008 at 1:01 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
>
>
> Good catch. I lost in basic arithmetic. What I see now that original
> definition count sizeof(ItemIdData) twice and on other side it does not take
> care about MAXALING correctly. I think correct formula is:
>
> #define
> What's the benefit of a multi-column GIN index over multiple
> single-column GIN indexes?
Page 12 from presentation on PgCon
(http://www.sigaev.ru/gin/fastinsert_and_multicolumn_GIN.pdf):
Multicolumn index vs. 2 single column indexes
Size:539 Mb538 Mb
Speed: *1.885* ms4.9
Heikki Linnakangas napsal(a):
Just one quick note:
Should probably use PageGetSpecialSize here. Much simpler, and doesn't
assume that the special area is always at the end of page (not that I
see us changing that anytime soon).
Thanks for review,
good catch. I found similar example also i
Dumb question:
What's the benefit of a multi-column GIN index over multiple
single-column GIN indexes?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.po
Pavan Deolasee napsal(a):
On Fri, Jun 13, 2008 at 9:38 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
I attached code cleanup which is related to in-place upgrade. I replace
direct access to PageHeader structure with already existing macros and I
removed also unnecessary retyping.
A quick review
Quoting daveg <[EMAIL PROTECTED]>:
On Wed, Jul 02, 2008 at 09:01:18AM -0700, David Fetter wrote:
On Wed, Jul 02, 2008 at 05:57:29PM +0200, Peter Eisentraut wrote:
> It would also be interesting if EXPLAIN could optionally be a
> function that returns a datum of type XML, to allow further
> proc
37 matches
Mail list logo
