Generic TVP tradeoffs?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








5















Is there a best practice or strategy for table types used in TVPs? For instance, given the following:



CREATE TABLE dbo.Colors (
Id int identity PRIMARY KEY,
Name nvarchar(100),
);

CREATE TABLE dbo.Shapes (
Id int identity PRIMARY KEY,
Name nvarchar(100),
);

CREATE TABLE dbo.Materials (
Id int identity PRIMARY KEY,
Name nvarchar(100),
);

CREATE TABLE dbo.Items (
Id int identity PRIMARY KEY,
Name nvarchar(100),
ColorId int FOREIGN KEY REFERENCES dbo.Colors (ID),
ShapeId int FOREIGN KEY REFERENCES dbo.Shapes (ID),
MaterialId int FOREIGN KEY REFERENCES dbo.Materials (ID),
);


If you implemented a stored procedure for searching items that needed to support selecting multiple colors, multiple shapes, and multiple materials via TVPs (think checkbox lists in the UI), would you create three separate table types, one for every TVP, or would you create a single type for using it across all three?



In other words, this:



CREATE TYPE dbo.ColorIds AS TABLE (Id int);
CREATE TYPE dbo.ShapeIds AS TABLE (Id int);
CREATE TYPE dbo.MaterialIds AS TABLE (Id int);
GO

CREATE PROCEDURE dbo.SearchItems
@ColorIds ColorIds READONLY,
@ShapeIds ShapeIds READONLY,
@MaterialIds MaterialIds READONLY
AS
BEGIN
PRINT 'Do something here'
END
GO


Versus this:



CREATE TYPE dbo.Ids AS TABLE (Id int);
GO

CREATE PROCEDURE dbo.SearchItems
@ColorIds Ids READONLY,
@ShapeIds Ids READONLY,
@MaterialIds Ids READONLY
AS
BEGIN
PRINT 'Do something here'
END
GO


The sample is deliberately contrived; the real use case consists of a lot more tables which although have different columns, all have a ID int primary key. Because of this, I personally am much more inclined to do the latter. It's far less overhead, but I'm curious to know if there are any cons I should be aware of in doing this. This is of course for TVPs and TVPs only (I would never mix different entities in a real table, or any other structure of a more permanent nature.)



While at it, what is your naming convention for naming table types and TVPs?










share|improve this question






























    5















    Is there a best practice or strategy for table types used in TVPs? For instance, given the following:



    CREATE TABLE dbo.Colors (
    Id int identity PRIMARY KEY,
    Name nvarchar(100),
    );

    CREATE TABLE dbo.Shapes (
    Id int identity PRIMARY KEY,
    Name nvarchar(100),
    );

    CREATE TABLE dbo.Materials (
    Id int identity PRIMARY KEY,
    Name nvarchar(100),
    );

    CREATE TABLE dbo.Items (
    Id int identity PRIMARY KEY,
    Name nvarchar(100),
    ColorId int FOREIGN KEY REFERENCES dbo.Colors (ID),
    ShapeId int FOREIGN KEY REFERENCES dbo.Shapes (ID),
    MaterialId int FOREIGN KEY REFERENCES dbo.Materials (ID),
    );


    If you implemented a stored procedure for searching items that needed to support selecting multiple colors, multiple shapes, and multiple materials via TVPs (think checkbox lists in the UI), would you create three separate table types, one for every TVP, or would you create a single type for using it across all three?



    In other words, this:



    CREATE TYPE dbo.ColorIds AS TABLE (Id int);
    CREATE TYPE dbo.ShapeIds AS TABLE (Id int);
    CREATE TYPE dbo.MaterialIds AS TABLE (Id int);
    GO

    CREATE PROCEDURE dbo.SearchItems
    @ColorIds ColorIds READONLY,
    @ShapeIds ShapeIds READONLY,
    @MaterialIds MaterialIds READONLY
    AS
    BEGIN
    PRINT 'Do something here'
    END
    GO


    Versus this:



    CREATE TYPE dbo.Ids AS TABLE (Id int);
    GO

    CREATE PROCEDURE dbo.SearchItems
    @ColorIds Ids READONLY,
    @ShapeIds Ids READONLY,
    @MaterialIds Ids READONLY
    AS
    BEGIN
    PRINT 'Do something here'
    END
    GO


    The sample is deliberately contrived; the real use case consists of a lot more tables which although have different columns, all have a ID int primary key. Because of this, I personally am much more inclined to do the latter. It's far less overhead, but I'm curious to know if there are any cons I should be aware of in doing this. This is of course for TVPs and TVPs only (I would never mix different entities in a real table, or any other structure of a more permanent nature.)



    While at it, what is your naming convention for naming table types and TVPs?










    share|improve this question


























      5












      5








      5








      Is there a best practice or strategy for table types used in TVPs? For instance, given the following:



      CREATE TABLE dbo.Colors (
      Id int identity PRIMARY KEY,
      Name nvarchar(100),
      );

      CREATE TABLE dbo.Shapes (
      Id int identity PRIMARY KEY,
      Name nvarchar(100),
      );

      CREATE TABLE dbo.Materials (
      Id int identity PRIMARY KEY,
      Name nvarchar(100),
      );

      CREATE TABLE dbo.Items (
      Id int identity PRIMARY KEY,
      Name nvarchar(100),
      ColorId int FOREIGN KEY REFERENCES dbo.Colors (ID),
      ShapeId int FOREIGN KEY REFERENCES dbo.Shapes (ID),
      MaterialId int FOREIGN KEY REFERENCES dbo.Materials (ID),
      );


      If you implemented a stored procedure for searching items that needed to support selecting multiple colors, multiple shapes, and multiple materials via TVPs (think checkbox lists in the UI), would you create three separate table types, one for every TVP, or would you create a single type for using it across all three?



      In other words, this:



      CREATE TYPE dbo.ColorIds AS TABLE (Id int);
      CREATE TYPE dbo.ShapeIds AS TABLE (Id int);
      CREATE TYPE dbo.MaterialIds AS TABLE (Id int);
      GO

      CREATE PROCEDURE dbo.SearchItems
      @ColorIds ColorIds READONLY,
      @ShapeIds ShapeIds READONLY,
      @MaterialIds MaterialIds READONLY
      AS
      BEGIN
      PRINT 'Do something here'
      END
      GO


      Versus this:



      CREATE TYPE dbo.Ids AS TABLE (Id int);
      GO

      CREATE PROCEDURE dbo.SearchItems
      @ColorIds Ids READONLY,
      @ShapeIds Ids READONLY,
      @MaterialIds Ids READONLY
      AS
      BEGIN
      PRINT 'Do something here'
      END
      GO


      The sample is deliberately contrived; the real use case consists of a lot more tables which although have different columns, all have a ID int primary key. Because of this, I personally am much more inclined to do the latter. It's far less overhead, but I'm curious to know if there are any cons I should be aware of in doing this. This is of course for TVPs and TVPs only (I would never mix different entities in a real table, or any other structure of a more permanent nature.)



      While at it, what is your naming convention for naming table types and TVPs?










      share|improve this question
















      Is there a best practice or strategy for table types used in TVPs? For instance, given the following:



      CREATE TABLE dbo.Colors (
      Id int identity PRIMARY KEY,
      Name nvarchar(100),
      );

      CREATE TABLE dbo.Shapes (
      Id int identity PRIMARY KEY,
      Name nvarchar(100),
      );

      CREATE TABLE dbo.Materials (
      Id int identity PRIMARY KEY,
      Name nvarchar(100),
      );

      CREATE TABLE dbo.Items (
      Id int identity PRIMARY KEY,
      Name nvarchar(100),
      ColorId int FOREIGN KEY REFERENCES dbo.Colors (ID),
      ShapeId int FOREIGN KEY REFERENCES dbo.Shapes (ID),
      MaterialId int FOREIGN KEY REFERENCES dbo.Materials (ID),
      );


      If you implemented a stored procedure for searching items that needed to support selecting multiple colors, multiple shapes, and multiple materials via TVPs (think checkbox lists in the UI), would you create three separate table types, one for every TVP, or would you create a single type for using it across all three?



      In other words, this:



      CREATE TYPE dbo.ColorIds AS TABLE (Id int);
      CREATE TYPE dbo.ShapeIds AS TABLE (Id int);
      CREATE TYPE dbo.MaterialIds AS TABLE (Id int);
      GO

      CREATE PROCEDURE dbo.SearchItems
      @ColorIds ColorIds READONLY,
      @ShapeIds ShapeIds READONLY,
      @MaterialIds MaterialIds READONLY
      AS
      BEGIN
      PRINT 'Do something here'
      END
      GO


      Versus this:



      CREATE TYPE dbo.Ids AS TABLE (Id int);
      GO

      CREATE PROCEDURE dbo.SearchItems
      @ColorIds Ids READONLY,
      @ShapeIds Ids READONLY,
      @MaterialIds Ids READONLY
      AS
      BEGIN
      PRINT 'Do something here'
      END
      GO


      The sample is deliberately contrived; the real use case consists of a lot more tables which although have different columns, all have a ID int primary key. Because of this, I personally am much more inclined to do the latter. It's far less overhead, but I'm curious to know if there are any cons I should be aware of in doing this. This is of course for TVPs and TVPs only (I would never mix different entities in a real table, or any other structure of a more permanent nature.)



      While at it, what is your naming convention for naming table types and TVPs?







      sql-server table-valued-parameters






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Mar 17 at 17:17







      Daniel Liuzzi

















      asked Mar 17 at 16:12









      Daniel LiuzziDaniel Liuzzi

      1285




      1285




















          1 Answer
          1






          active

          oldest

          votes


















          6














          I personally use the latter, more generic version in my systems. I have two tables that I can think of off the top of my head: UniqueIntegerTable and UniqueStringTable - as you can imagine, they are defined as follows:



          CREATE TYPE Utils.UniqueIntegerTable AS TABLE (
          [Value] INT NOT NULL PRIMARY KEY
          );
          CREATE TYPE Utils.UniqueStringTable AS TABLE (
          [Value] NVARCHAR(50) NOT NULL PRIMARY KEY
          );


          I prefer to have generic TVP's so that I don't clog up my schema's with multiple types that are basically the same. The performance is exactly the same as if you defined an explicit type as in your first example and it has the benefit that it creates less code for me to maintain.



          I know one argument that I have previously heard for using explicit types that are bound to tables is that it is easier to understand their usage. I personally don't agree with this. There is nothing preventing me from defining a stored procedure using the wrong type (but has the correct shape for my needs). Instead, I can give the variable a good name to infer usage and the contents of the table:



          CREATE PROCEDURE dbo.UpdateEmployees (
          @employeeIds Utils.UniqueIntegerTable READONLY
          )
          BEGIN
          SET NOCOUNT ON;

          -- Use table as needed.

          END
          GO


          In terms of naming conventions, I don't know of any official standard but the one I use is to append Table to the end of the type name. I know that this is not really all that different from prefixing things with tbl but I'm ok with it in this instance. As with all naming conventions, pick one that you feel is easy to work with it - but once you do, stick to it. Naming conventions are only useful if you are consistent.






          share|improve this answer




















          • 2





            Totally agree with the nothing stopping you from using the wrong type part. In fact, right before posting the question I was checking if there is anything like FK constraints for table types. Didn't find anything. If there was one argument to push me over to favoring specific types, that would have been it. I'm sort of glad it wasn't the case!

            – Daniel Liuzzi
            Mar 17 at 17:13












          • Yeah, you definitely can't define a foreign key to a table type. I think if it was anything more than a glorified temp table and had a lot more functionality, then I would use explicit types. But as it stands, less maintenance means I can spend more time doing things that are important, rather than worrying about whether I have passed the right type to a stored procedure. ;-)

            – Mr.Brownstone
            Mar 17 at 17:16











          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "182"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f232372%2fgeneric-tvp-tradeoffs%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          6














          I personally use the latter, more generic version in my systems. I have two tables that I can think of off the top of my head: UniqueIntegerTable and UniqueStringTable - as you can imagine, they are defined as follows:



          CREATE TYPE Utils.UniqueIntegerTable AS TABLE (
          [Value] INT NOT NULL PRIMARY KEY
          );
          CREATE TYPE Utils.UniqueStringTable AS TABLE (
          [Value] NVARCHAR(50) NOT NULL PRIMARY KEY
          );


          I prefer to have generic TVP's so that I don't clog up my schema's with multiple types that are basically the same. The performance is exactly the same as if you defined an explicit type as in your first example and it has the benefit that it creates less code for me to maintain.



          I know one argument that I have previously heard for using explicit types that are bound to tables is that it is easier to understand their usage. I personally don't agree with this. There is nothing preventing me from defining a stored procedure using the wrong type (but has the correct shape for my needs). Instead, I can give the variable a good name to infer usage and the contents of the table:



          CREATE PROCEDURE dbo.UpdateEmployees (
          @employeeIds Utils.UniqueIntegerTable READONLY
          )
          BEGIN
          SET NOCOUNT ON;

          -- Use table as needed.

          END
          GO


          In terms of naming conventions, I don't know of any official standard but the one I use is to append Table to the end of the type name. I know that this is not really all that different from prefixing things with tbl but I'm ok with it in this instance. As with all naming conventions, pick one that you feel is easy to work with it - but once you do, stick to it. Naming conventions are only useful if you are consistent.






          share|improve this answer




















          • 2





            Totally agree with the nothing stopping you from using the wrong type part. In fact, right before posting the question I was checking if there is anything like FK constraints for table types. Didn't find anything. If there was one argument to push me over to favoring specific types, that would have been it. I'm sort of glad it wasn't the case!

            – Daniel Liuzzi
            Mar 17 at 17:13












          • Yeah, you definitely can't define a foreign key to a table type. I think if it was anything more than a glorified temp table and had a lot more functionality, then I would use explicit types. But as it stands, less maintenance means I can spend more time doing things that are important, rather than worrying about whether I have passed the right type to a stored procedure. ;-)

            – Mr.Brownstone
            Mar 17 at 17:16















          6














          I personally use the latter, more generic version in my systems. I have two tables that I can think of off the top of my head: UniqueIntegerTable and UniqueStringTable - as you can imagine, they are defined as follows:



          CREATE TYPE Utils.UniqueIntegerTable AS TABLE (
          [Value] INT NOT NULL PRIMARY KEY
          );
          CREATE TYPE Utils.UniqueStringTable AS TABLE (
          [Value] NVARCHAR(50) NOT NULL PRIMARY KEY
          );


          I prefer to have generic TVP's so that I don't clog up my schema's with multiple types that are basically the same. The performance is exactly the same as if you defined an explicit type as in your first example and it has the benefit that it creates less code for me to maintain.



          I know one argument that I have previously heard for using explicit types that are bound to tables is that it is easier to understand their usage. I personally don't agree with this. There is nothing preventing me from defining a stored procedure using the wrong type (but has the correct shape for my needs). Instead, I can give the variable a good name to infer usage and the contents of the table:



          CREATE PROCEDURE dbo.UpdateEmployees (
          @employeeIds Utils.UniqueIntegerTable READONLY
          )
          BEGIN
          SET NOCOUNT ON;

          -- Use table as needed.

          END
          GO


          In terms of naming conventions, I don't know of any official standard but the one I use is to append Table to the end of the type name. I know that this is not really all that different from prefixing things with tbl but I'm ok with it in this instance. As with all naming conventions, pick one that you feel is easy to work with it - but once you do, stick to it. Naming conventions are only useful if you are consistent.






          share|improve this answer




















          • 2





            Totally agree with the nothing stopping you from using the wrong type part. In fact, right before posting the question I was checking if there is anything like FK constraints for table types. Didn't find anything. If there was one argument to push me over to favoring specific types, that would have been it. I'm sort of glad it wasn't the case!

            – Daniel Liuzzi
            Mar 17 at 17:13












          • Yeah, you definitely can't define a foreign key to a table type. I think if it was anything more than a glorified temp table and had a lot more functionality, then I would use explicit types. But as it stands, less maintenance means I can spend more time doing things that are important, rather than worrying about whether I have passed the right type to a stored procedure. ;-)

            – Mr.Brownstone
            Mar 17 at 17:16













          6












          6








          6







          I personally use the latter, more generic version in my systems. I have two tables that I can think of off the top of my head: UniqueIntegerTable and UniqueStringTable - as you can imagine, they are defined as follows:



          CREATE TYPE Utils.UniqueIntegerTable AS TABLE (
          [Value] INT NOT NULL PRIMARY KEY
          );
          CREATE TYPE Utils.UniqueStringTable AS TABLE (
          [Value] NVARCHAR(50) NOT NULL PRIMARY KEY
          );


          I prefer to have generic TVP's so that I don't clog up my schema's with multiple types that are basically the same. The performance is exactly the same as if you defined an explicit type as in your first example and it has the benefit that it creates less code for me to maintain.



          I know one argument that I have previously heard for using explicit types that are bound to tables is that it is easier to understand their usage. I personally don't agree with this. There is nothing preventing me from defining a stored procedure using the wrong type (but has the correct shape for my needs). Instead, I can give the variable a good name to infer usage and the contents of the table:



          CREATE PROCEDURE dbo.UpdateEmployees (
          @employeeIds Utils.UniqueIntegerTable READONLY
          )
          BEGIN
          SET NOCOUNT ON;

          -- Use table as needed.

          END
          GO


          In terms of naming conventions, I don't know of any official standard but the one I use is to append Table to the end of the type name. I know that this is not really all that different from prefixing things with tbl but I'm ok with it in this instance. As with all naming conventions, pick one that you feel is easy to work with it - but once you do, stick to it. Naming conventions are only useful if you are consistent.






          share|improve this answer















          I personally use the latter, more generic version in my systems. I have two tables that I can think of off the top of my head: UniqueIntegerTable and UniqueStringTable - as you can imagine, they are defined as follows:



          CREATE TYPE Utils.UniqueIntegerTable AS TABLE (
          [Value] INT NOT NULL PRIMARY KEY
          );
          CREATE TYPE Utils.UniqueStringTable AS TABLE (
          [Value] NVARCHAR(50) NOT NULL PRIMARY KEY
          );


          I prefer to have generic TVP's so that I don't clog up my schema's with multiple types that are basically the same. The performance is exactly the same as if you defined an explicit type as in your first example and it has the benefit that it creates less code for me to maintain.



          I know one argument that I have previously heard for using explicit types that are bound to tables is that it is easier to understand their usage. I personally don't agree with this. There is nothing preventing me from defining a stored procedure using the wrong type (but has the correct shape for my needs). Instead, I can give the variable a good name to infer usage and the contents of the table:



          CREATE PROCEDURE dbo.UpdateEmployees (
          @employeeIds Utils.UniqueIntegerTable READONLY
          )
          BEGIN
          SET NOCOUNT ON;

          -- Use table as needed.

          END
          GO


          In terms of naming conventions, I don't know of any official standard but the one I use is to append Table to the end of the type name. I know that this is not really all that different from prefixing things with tbl but I'm ok with it in this instance. As with all naming conventions, pick one that you feel is easy to work with it - but once you do, stick to it. Naming conventions are only useful if you are consistent.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Mar 17 at 16:57

























          answered Mar 17 at 16:52









          Mr.BrownstoneMr.Brownstone

          10.1k32546




          10.1k32546







          • 2





            Totally agree with the nothing stopping you from using the wrong type part. In fact, right before posting the question I was checking if there is anything like FK constraints for table types. Didn't find anything. If there was one argument to push me over to favoring specific types, that would have been it. I'm sort of glad it wasn't the case!

            – Daniel Liuzzi
            Mar 17 at 17:13












          • Yeah, you definitely can't define a foreign key to a table type. I think if it was anything more than a glorified temp table and had a lot more functionality, then I would use explicit types. But as it stands, less maintenance means I can spend more time doing things that are important, rather than worrying about whether I have passed the right type to a stored procedure. ;-)

            – Mr.Brownstone
            Mar 17 at 17:16












          • 2





            Totally agree with the nothing stopping you from using the wrong type part. In fact, right before posting the question I was checking if there is anything like FK constraints for table types. Didn't find anything. If there was one argument to push me over to favoring specific types, that would have been it. I'm sort of glad it wasn't the case!

            – Daniel Liuzzi
            Mar 17 at 17:13












          • Yeah, you definitely can't define a foreign key to a table type. I think if it was anything more than a glorified temp table and had a lot more functionality, then I would use explicit types. But as it stands, less maintenance means I can spend more time doing things that are important, rather than worrying about whether I have passed the right type to a stored procedure. ;-)

            – Mr.Brownstone
            Mar 17 at 17:16







          2




          2





          Totally agree with the nothing stopping you from using the wrong type part. In fact, right before posting the question I was checking if there is anything like FK constraints for table types. Didn't find anything. If there was one argument to push me over to favoring specific types, that would have been it. I'm sort of glad it wasn't the case!

          – Daniel Liuzzi
          Mar 17 at 17:13






          Totally agree with the nothing stopping you from using the wrong type part. In fact, right before posting the question I was checking if there is anything like FK constraints for table types. Didn't find anything. If there was one argument to push me over to favoring specific types, that would have been it. I'm sort of glad it wasn't the case!

          – Daniel Liuzzi
          Mar 17 at 17:13














          Yeah, you definitely can't define a foreign key to a table type. I think if it was anything more than a glorified temp table and had a lot more functionality, then I would use explicit types. But as it stands, less maintenance means I can spend more time doing things that are important, rather than worrying about whether I have passed the right type to a stored procedure. ;-)

          – Mr.Brownstone
          Mar 17 at 17:16





          Yeah, you definitely can't define a foreign key to a table type. I think if it was anything more than a glorified temp table and had a lot more functionality, then I would use explicit types. But as it stands, less maintenance means I can spend more time doing things that are important, rather than worrying about whether I have passed the right type to a stored procedure. ;-)

          – Mr.Brownstone
          Mar 17 at 17:16

















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Database Administrators Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f232372%2fgeneric-tvp-tradeoffs%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown






          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Displaying single band from multi-band raster using QGIS

          How many registers does an x86_64 CPU actually have?